Scope Management : A Core Information System Implementation Project Pedagogy

This article describes an initiative to provide IS management a capstone course that builds on the zone of proximal development concept, oriented towards developing prioritization and critical reasoning skills, and to promote self-learning. Request for proposal business cases appear to offer effective mechanisms for retaining context, while constraining scope for academic purposes.


Introduction
ERP systems are commercial off-the-shelf software packages that are purposely built with a wide variety of configurable functionalities meant to support the business needs of organizations (Brehm, Heinzl and Markus, 2001).The implementation of these business applications often requires IT business analysts that help the organization select the appropriate options and configure the software according to their needs.The training of these analysts requires that they are exposed to a wide variety of business processes and software solutions to develop their skills at finding and adapting the right technological solutions.Although we are talking about IT students, the focus is on business analysis, even though the end solution will involve the application of technology.
(2004) called for a second wave of ERP education that goes beyond the simple demonstration of the potential of the application.They suggest more innovative and strategic use of the technology to train IS graduates on problem resolution approaches.In a similar manner, Pellerin and Hadaya (2008) stress the importance of centering the learning process on the business process redesign instead of putting all the emphasis on the ERP implementation.Léger (2006) and Leger et al. (2012) suggests a simulation game approach to provide hands-on experience with the main functionality of an ERP.Overall, their results show that students tend to learn more by applying the skills required in conducting successful process improvement projects.
When we consider ERP implementation project complexity, it is largely the business process re-engineering that drives the level of complexity, which is then propagated to the technology used to support that process, and not the other way around.It can also be argued that by spending more effort to reduce business process complexity and yet accomplish the same organizational goals; implementation cost, complexity and therefore risk are significantly reduced.In this paper, we explore the learning process of IT students.We are particularly interested in developing their ability to perform project scope management.To this end, we propose a novel course curriculum and teaching approach, that we believe will maximize their learning.We describe how the proposed approach was used in class and reflect on the observed outcomes from the experiment.

Vocational Learning in the Context of IS Projects
For Surendra and Denton (2009, p. 77), IT graduates must be able to "assess and understand organizational requirements and opportunities in ambiguous and messy organizational situations and design systems that accomplish requirements and leverage opportunities."The structure of traditional curriculum places emphasis on the transfer of knowledge of technology specifics, techniques and methodologies and how to use these within the context of illustrative examples.Instructors usually set a problem and demonstrate how to solve it.Then a different problem is proposed to students who need solve it the same way.Finally the theory is provided about how to manage one complex problem as well as how to deal with complexity of situations and contexts.
After hire, a typical IT analyst will go through an induction or other onboarding program to become familiar with organizational policies and procedures, and any resources such as documentation or other knowledge repositories that are available to assist them in performing their duties.After that, they are soon assigned to a team and a project, and expected to learn as they go.
The knowledge transfer of specific technologies, techniques and methods, although necessary, is not sufficient acquired learning to achieve the level of competency needed in students for them to succeed after graduation.(Debuse and Lawley, 2009;Aasheim, Li and Williams, 2009;Lee and Han, 2008).They must be able to apply this knowledge beyond limited contexts and limited complexity.There is an expectation to be able to achieve some degree of independent work.The less supervision required, and the more quickly this level matches what is typical for the hiring organization, the more competent the new hire is perceived to be.Conversely, too great a need for supervision, or lack of ability to accomplish independent work of low complexity, results in a perception of low competency.Vygotsky (1978) introduced the concept of the zone of proximal development (ZPD) -the difference in competency an individual has when asked to perform a task on their own, compared with their competency while under the guidance and assistance of someone with greater competency.By being given tasks between these two points, learning can occur, and as a result these points shift -the individual is able to accomplish the same task with less assistance, and more complex tasks that were previously beyond their competency.The width of the ZPD can also be linked with confidence.Individuals lacking in confidence will not attempt tasks even with promised assistance, or simply require too much assistance for any learning to actually occur.
Typically associated with early childhood models of development, the ZPD concept also applies to vocational learning where guidance and assistance are synonymous with supervision, coaching and mentoring.As discussed above, there are expectations of minimum competency and how much time is willing to be spent supervising, both of which relate to the complexity of the given task.For an individual to be perceived as competent, the total range of tasks they are able to perform under varying levels of supervision must be below the upper bound of their ZPD, but above the lower bound of the level of supervision that will be tolerable to those providing assistance.Over time, they are expected to require less supervision for those same tasks and to be able to attempt more complex tasks.Therefore, the competency expected of them is that which places the complexity of the tasks assigned to them between the two points of their ZPD.

Closing the Gap: New Pedagogy for ERP Systems
The gap between their attained level of competency and that which is required is the challenge for each student to succeed at their new job.To produce students that meet industry expectations of competency at graduation requires IS curricula to accomplish at least three things: Firstly, to ensure that the tasks that they are at least able to attempt with minimal assistance are as complex as the simplest tasks they would be assigned.Secondly, that the range in complexity of tasks attemptable with supervision is wide enough to encompass the range of tasks they are likely to be faced with.This second aim is additionally important in that it also increases their chance for on-the-job learning.Finally, and most importantly of all, is the need to reconnect students with the vocational learning model itself.This last point may not be obvious or seem particularly problematic.However, the grading structure at most universities encourages thinking that anything less than a perfect solution is a level of failure, and that the perfect solution is always both possible and attainable by the student.When faced with the complexity of the real world, this expectation can cripple the confidence of the student, resulting in a narrow ZPD.They simply do not perceive that they have any chance at solving problems of that complexity, and relegate themselves to willing hands to be given specific tasks that they can accomplish unsupervised.This is at odds with what is actually expected, and denies them the opportunity for learning.
Conversely, a perfect solution may not be well received, on account of its cost to develop, implement or operate.The Pareto Principle often applies here; arriving at a solution that addresses 80% of the problem is usually easy to accomplish, but the remaining 20% of the solution is increasingly difficult and more costly to attain.The best solution is the one with the most value for the least cost, and not the one which solves the issue the most completely.
Additionally, in universities exams and assignment questions are visited once.While there is learning from failure and reflection, the exact same problem is never revisited twice.Contrast this with the world beyond the classroom, where the re-visitation of unsolved challenges is not only possible, but often unavoidable as we must continually carry the burden of them until they are solved.In this world, a partial solution has great value, since we continually reap the rewards, can use it over time to better understand the nature of the challenge and build better solutions on top of it.But many students do not realize it is acceptable to, or know how to, divide or reframe complex problems into simplified parts and forms.
To achieve these aims, IT students must be placed in a situation where they gain experience, that is, the application of their knowledge and skills to context.This learning environment must be sufficiently close to the real context they will face after graduation (Boyle and Strong, 2006), but still within their reach in order to transfer their learning into practice.It is difficult and time consuming to create such environments and find such exercises, and both may be beyond the reach of the teacher, depending on their own level of experience with real world complexity.
If we can frame exercises in curriculum that will bring students to this awareness -that partial solutions have great value -we can preserve the complexity of reality when we bring it into the classroom.We need to develop the critical reasoning and self-sufficiency skills of students that will allow them to adapt to new contexts, and work through complexity.Given the pace of technological innovation, and the challenge for organizations to find, adopt and exploit competitive advantage at ever increasing rates, it is this very adaptability that is essential to the long term career prospects of every IT analyst.
We must set them more than one problem; firmly embedded in situational complexity as well, together to create project complexity such that the solution is no longer definite or clear.A trade-off assessment has to be madevalue vs. feasibility and risk.In other words, the project must be made more difficult; not by adding multiple independent problems; but by increasing the interconnectedness between component problems, the related technology used to devise solutions, and the situational context to increase overall complexity.
The challenge is that putting all these elements together in an experience that is complex and rich is by nature unstructured.But enough structure is required to guarantee learning and a way to measure (grade) the learning that has actually occurred.Additionally, the demand on the student's time must be constrained.A problem that is too complex to resolve in the time allotted, or too difficult to dissect or simplify, is likely to demotivate students.To bring relevance to the learning, it is advisable to use current commercial technologies but we must consider that using systems such as ERP systems, can become overwhelming (Fedorowicz, Gelinas, Usoff and Hachey, 2004), particularly for students that lack exposure or training to technology of that nature.
To accomplish this, for students with a range of backgrounds and pre-requisite training, we need a mechanism that allows for a wide range in the complexity of the solutions that students might develop given the same business case, rather than trying to develop different business cases of varying complexity.In doing so, we seek to find the level of complexity within the reach of each student to facilitate learning and maintain the original context to enable them to transfer that learning to other similar contexts.With both of these, we advance their competency and promote their confidence, which hopefully widens their ZPD.

IS Project Scope Management
Requirements or scope management is often presented simplistically in project management theory.Something is required or it isn't -it is simply either "in" or "out" of scope.As per the previous discussion however, we are able to create, and place value on the creation of partial solutions.This hidden aspect of project scope is what makes requirements elicitation and scope management critical success factors to projects.Poor requirements elicitation can be framed as an underestimation of the complexity of the business need, or the unconsidered possibility of partial value solutions.As the finer details of business needs are uncovered, scope management, or more accurately, scope complexity management is essential in order to maintain perspective and priority, and prevent the project falling into panicked chaos.In essence, scope management seeks to find that level of complexity in the solution to any given business need that yields the most gain, but is reasonably achievable for the time, cost and risk that the project sponsors are willing to bear.
It is for this reason that mature requirements management processes focus on ascertaining underlying business needs, and move away from stating one particular solution as the requirement.If the stated solution proves complex, you are left with the in/out-of scope choice, neither of which is appealing -the former due to increased cost and/or risk; the latter due to failure to meet the objectives of the project.This ability to adjust the complexity of the problem and solution is realistic.There is typically an inverse or diminishing return between the cost and the value of the developed solution, not only in terms of the cost of development and implementation, but also in terms of ongoing operational costs.There is a natural limit to scope complexity in that the marginal value of more complete solutions at some point are less than the cost to develop and operate them.Coupled with the traditional scope constraint of limited resources to complete the project, setting the project scope is no longer a trivial decision.In fact, finding creative mid-point solutions with excellent cost-benefit trade-offs can be the most value an IT analyst can contribute to a project.
There are two other aspects of scope complexity in addition to business complexity.Technical complexity, also sometimes referred to as feasibility, plays a large role in any IT project.For any solution, there is a question of fit of any and all the technology choices available to support that solution.The higher the business complexity of the solution desired, the more sophisticated the technology required, either to make the complexity manageable, or to achieve efficiency, or both.As solutions become more complex, the ability to adapt existing software solutions becomes more limiting, and the testing effort increases.The skill of the project team must also be considered.How long will it take the implementation team to master any of the proposed technologies, based on their existing skills and prior adoption experiences?What is the risk to schedule slippage and technology failure if the technology and its application to the problem domain are new to the team?Might it be better to use a technology less suited to supporting the solution, but more familiar or "proven" to the implementation team, so as to reduce project risk?
The final aspect of scope complexity is scope interdependency.For a complex end-to-end business problem, there may be many parts to the solution.Data may have to be captured first, analyzed, and then made transparent for decisions further down the value chain.Accuracy and timeliness affect the complexity and value of the solution.These parts are connected, without one there is no complete solution.This is where traditional in/out scope thinking can fail.A project that is defined in its requirements too ambitiously has a high risk of running over time and over budget, if defined in such a way that none of the scope can be removed on account of interdependency.
But this is an artificial limitation.The ability to say: "we can build a partial solution, we can start somewhere and learn from that, build upon that," is the essence of innovation.We should ensure that projects allow for this scaling of solutions, that the project management process and organizational culture focus on business need, value partial success, and more importantly that the project team see it as a possibility.
To visualize this concept, we can think of a tree.The trunk supports the branches which hold the leaves.Even if we know that the ultimate goal is to have a complete the tree, we can begin by concentrating on the trunk and then main branches first.Even though not perfect, it is still recognizable as a tree, and potentially a solid basis for further work to have a better tree.Bringing all three of these scope complexity aspects together, we find they are loosely related.Increased solution complexity requires more complex technology.Increased interconnectedness of "in" scope functionality requires increased solution complexity, or more sophisticated technology to mitigate and manage interrelation.With these three aspects affecting and mutually constraining scope complexity, we adopt the term "scope cube" as an appropriate visualization of the true scope management question in play for non-trivial IT projects (Fig. 1).

Figure 1. Scope Cube
Finally, no understanding of the challenges of adapting IT solutions to meet complex business needs can be completed without experiencing the full cycle of an implementation project.The impact of poor planning, decisions based on limited information, and poor requirements elicitation is not experienced if the project is only experienced on paper, or never beyond the planning phase.Risk assessment and mitigation is essential to the success of any project, and linked to scope ambition, not only in the planning phase but in responding to actual unfavourable eventualities along the way.
These aspects of scope management make it an important topic for the education of competent business analysts, who are the curators of the conversation between business and technology.This is also an excellent vehicle for the framing of the type of complexity exposure exercise we are looking for.The challenge is to find a context where the scope of the project is completely flexible, so that the full range of possibilities can be experienced positively; i.e., as reality meets ambition, scope adjustments are seen as necessary and realistic and not as failure.We want to allow for a lot of ambition, and yet still reward the simple, most minimal solution possible as a success and not failure.

Objectives of the Proposed Curriculum
In our approach, we aim to create a hierarchy of complexity, as opposed to a breadth of complexity.That is to say, the solutions formulated to one part of the problem impact or limit the complexity of solutions to the rest of the problem.With this problem scope, we create the interesting dynamic of scope management that is beyond "in" or "out" of scope decision-making.The scale of the original business problem, the complexity of solution, can be adjusted to fit the business needs.Or more specifically the level of business value created by the solution can be targeted.
We create enough complexity such that the perfect solution is not immediately apparent or more likely not unattainable at all by most if not all of the students.By tapping into typical student expectations of perfect solutions, this places their perceived task as well beyond their ZPD.This objective serves two purposes.To highlight the need for problem dissection and simplification, and later as a confidence booster when students realize they are able to accomplish something valuable in contrast with an assignment that they initially thought impossible.
The emphasis on the exercise is for students to learn the importance of compromise and prioritization, how to assess business value delivered from IT, and the process of solution emergence that comes from critical thinking, trial and error, and self-learning.Acquisition of specific solutions for specific problems with specific technologies is de-emphasised as the goal.These are only useful if they can be adapted into more effective solutions, similar problems, and different technologies.
A final objective is that the pedagogy must allow for the guidance and assistance element of the ZPD concept, typically from the instructor.Opening up this role to teammates however could be especially enriching, as it's a closer match to work environments.More experienced coworkers, not supervisors, often play key roles in getting new recruits up to speed, and yet also have less tolerance for the extent and duration for which they are required to give assistance.Given different backgrounds and aptitudes between students, we don't think this is unrealistic.

Request for Proposal (RFP) with Proof of Concept
Building upon the suggestion of Seyed-Abbassi, King, and Wiseman.( 2007), we suggest a real-world business project, realistic business scenario, and collaboration between business and academia.This allows for a lot of scope, in terms of complexity as well as breadth even to the point of customer "wish list" distractions.We suggest this be a team exercise, but even so, students obviously cannot be expected to actually deliver a project of this scope.
To retain both context and scope complexity, we reframe the deliverable for the project as a proposal, instead of an actual working solution.Students must formulate a proposal, and "sell" it on paper, however to keep it honest and not have it turn into an ambitious "slideware" exercise, part of the proposal is to deliver a partially functioning prototype.This proof of concept may be barely functional, but is meant to highlight the key aspects of the proposed solution, and act as a check and balance to viability.It is a competitive experience.Each team takes the role of a 3rd party integrator, and only one will "win" the contract based on the strength of their proposal.There is no formal prize or any tangible benefit, but for the purpose of completing the experience, a clear winner is defined.
Since the complete scope does not have to be delivered, only understood, the student workload is constrained and the situational complexity retained.Additionally, for the functional prototype, this is where we can have the most fun.Here, scope is completely within the control of the students.They can be as ambitious as they like, or as conservative as they like -even to the point of screenshot mock-ups only.
It also allows us to meet our objective of providing the guidance and assistance element.The instructor may coach the students into adjusting what is in-scope, and help them prioritize various elements of the final solution.They may also provide them key technical assistance to get over particular hurdles, but suggestions on where to find the answer, or how to experiment and find it for themselves, are likely to be better linked to the objectives of self-sufficiency.Most importantly the instructor is likely to need to intervene regularly to provide guidance on what are acceptable dissections and simplifications of the overall problem, and what are not.Team members with strong business acumen also have potential to fill this role, while those with stronger technical skills can provide guidance with regard to what is feasible to implement given resource constraints.
To remove focus from the completeness of the prototype, and place more emphasis on the overall approach and proposal, we suggest that grading mechanisms be adjusted accordingly.This is to downplay feelings of failure and hopelessness from the students but encourage them to try.It is also an effective mechanism for prioritization conversations that reflect the real world.Students often link effort to grades, which is in opposition to the grading weightings we suggest.However, in typical RFP situations, a lot of work is expended on proposals that are ultimately won by only one vendor.The message is to prioritize and build enough of the right pieces of the overall solution to show enough value, but not so much as to incur great expense for a solution that the customer may not agree with.This is completely in line with the learning objectives of the exercise.
With this framing, and creating a representative scope cube for the project, we are not teaching how to solve a business problem separate from that of how to then resolve the proposed business solution with technology.It is about learning to make the tradeoffs between value, cost, and risk together.More specifically, it is about the lesson of simplifying the level of sophistication of the business problem that we choose to solve, in order that the solution is feasible given the technology that is available, and time and budget constraints.This is the competency that businesses are looking for -to formulate solutions that create value and are achievable within environments filled with complexity and uncertainty.

Context
The experiment was performed in a capstone course in the undergraduate program for business students specializing in IT.A 60 page request for proposal was prepared to describe the business problem, including all the elements described above.Some support was provided by the collaborating enterprise in the creation of the request for proposal -clarification questions, initial proposal verification, final proof of concept, and proposal judging.

Project Description
The essence of our RFP problem was related to cost visibility and allocation in a manufacturing enterprise.Each item manufactured by the enterprise has an associated variable production cost, which varies from one production batch to another.The client needed to carry these costs over to a pricing model, such that they could ensure those costs were reclaimed and they made a profit.The problem complexity in this case dealt with the need to capture in an efficient manner costs as they occur, and carry or allocate those costs through the value chain and input them into the pricing decision.The situational complexity came from the distributed nature of the business.Any part of any production run could be sent to any warehouse, and at the time of sale, the stock in a warehouse could have come from any number of production runs, or even different factories.And yet, the customer wanted a single, simple price quotation.To resolve this problem, a solution for accurate cost capture had to be developed, along with a solution for cost allocation or identification along the distribution chain.The complexity of the second solution was constrained by the timeliness and level of granularity of the proposed cost capture solution.There was no decision to put either part of the problem in or out of scope.Both need to be included on some level in order to have any kind of solution.Limited scope would be to capture all production costs together, irrespective of location, and simply use the global average cost in the pricing decision.Scope complexity could be increased by capturing costs and calculating an average per factory, and then calculating an average cost per warehouse based on the history of which plants supplied which warehouse.Full scope would capture and propagate the exact cost history of every item in inventory right up until the point of delivery for a sale.
To address the third aspect of scope complexity, technical complexity, we made available a choice of technologies to be used to deploy the solution.Some were better adapted to certain solutions than others.The complexity of cost capture and allocation possible in the underlying operational ERP system had to be discovered.If the chosen technology already supported the need, the cost of the solution would be less than if a customization would need to be made.Students had to find these limits and make the value/cost assessment in order to make their proposal.
The best practices provided by the software editor are an excellent resource to explore different solution opportunities, because they are comprehensive and extensive, but being best practices, are not guaranteed to be complete solutions in most contexts.Students had to adapt, assemble and extend more than one best practice into their final solution.Additionally, the best practices offered ways to form part of the solution involving cost capture and business process re-configuration, but a completely different set of technologies had to be used to build the final end-user experience.
For this last part, various technical alternatives were briefly presented and teams had to choose which of them to use to complete their solution.Enough information was given for students to assess viability/feasibility given their own skills and competencies, but not enough to complete their solutions.Self-learning in their chosen technical solution was required.After identifying and understanding the business problems, students needed to evaluate the available technologies and associated best practice applications for degree of usefulness in solving those business problems.The pedagogical objective here was to learn how to explore and match many possible technical solution sets to the solving (or partial solving) of specific business problems.
At the end of the semester, students had to present their solution to a panel of reviewers from the collaborating enterprise.Feedback was provided with respect to the level of understanding of the problem communicated; appropriateness of the level of complexity tackled; and the image of competency they were able to create by the content and style of their presentation.

The Challenges of Scope Management
In the RFP framing, all scope dimensions are under complete control of the teams.There was no mandated minimum set of requirements, only to have "something working" and a motivation to have better solutions than the competition.During the semester, another scope dimension not traditionally thought of as "scope" was discovered -the quality of the implemented solution.Since a prototype was all that was being developed, the level of quality is completely optional.In real projects, this is less the case, but quality is easily sacrificed when faced with schedule and budget constraints and traditional scope (requirements) cannot be reduced.To extend the scope cube analogy, quality can be thought of as cube density.Given a cube of particular scope, resources and time expended on the project fill the cube uniformly.Fewer resources spent results in reduced quality for the same scope, or a less "solid" cube.
The reaction of most of the students to adjusting solution complexity and sacrificing quality was that it was "cheating."Faced with no other options, and some assurance that it was a perfectly appropriate response to a project in jeopardy, particularly in the RFP context, they all embraced this thinking.From there, the challenge for the students was to identify the component parts of the various business problems, and their interconnectedness.Here, true learning about understanding business requirements can occur.Creativity in finding multiple solutions at different complexity levels to the same business problems was difficult for the students, and significant coaching was necessary.Once guided however, spirited discussion about how to prioritize these, and formulate risk assessment and mitigation strategies was observed.
Finally, the greatest challenge was then to propose and convince the customer that their chosen scope and prioritization had sufficient business value.This appeared to be an entirely new world of discovery for most of the students, on which they frequently commented on aspect of the learning that they had experienced by semester end.

Selling the Solution to the Customer
Students discovered that it was not about finding the right answer, as they were typically accustomed to, but about choosing a solution that would be feasible and "sellable" to the customer -that is, choosing the level of sophistication that generates enough perceived business value with project cost that the customer is willing to accept.The students also learned that defence and elaboration of choices made is an important factor in generating client confidence and the perception of credibility to execute the proposed project successfully within budget and schedule.
There was a range of business problems, scope for the adjustment of complexity willing to be addressed within those business problems and a range of technical alternatives that could be used to solve one or more of each of those business problems (many-to-many relationship between business problem and technology).This allowed a rich selection for the technology dimension of the scope cube, and every team proposed a different technology set.Again, the need to propose and to convince the customer that their chosen technology was best and came without significant risk that could not be avoided or mitigated, was something new for the students.Many commented on the reflection that the most sophisticated or advanced technology should not automatically be chosen if you cannot demonstrate its value for its cost and associated risks.Some business problems were not solvable with any of the technologies (business complexity high); some were solvable with only some of the technologies (technical complexity varies in context); some were limited by technical feasibility (business complexity reduced by assumption in order to meet technical feasibility).This was where the real learning about scope management and business/technology/risk tradeoffs was aimed.The firsthand experience of ambition and subsequent confrontation with reality was a rich experience for all.
Communication was another required competency -to articulate the comprehension of the business problems as well as clearly describe the proposed solution and its merits and shortcomings.Different styles of communication, for different audiences were also covered.A written proposal, a live technical demonstration, and an oral summation were all mandated.

Working in Teams
Working in teams created an additional complexity -communication, consensus (especially repeat consensus as scope decisions were constantly revisited), conflict management, resource management, and skills assessment were important aspects that each team had to deal with.Of course, the traditional concept of applying methodologies and techniques they have already learned into solving complex business problems were still an important factor.In this context, they had to learn how to find consensus to match the problem with the right methodology to resolve the problem.The competitive element created both excitement and anxiety for the students.Convinced that there were real consequences to their choices, some healthy debates about trade-offs were observed.This generated an incredible level of emotional reactions, both positive and negative, with many switches between the two.

Proposed Curriculum
To summarize this approach, the following table presents the week-by-week curriculum used in this course.This is a standard AACSB curriculum over a period of 12 weeks (3 hours weekly).The course is organized in four phases.In Phase 1 (Week 1 to Week 3), the students discover the RFP.They are assigned to teams, and must prepare an interview with the customer.On Week 3, they conduct a business requirements analysis interview with the real customer.For many of them, this is their first experience at eliciting business needs in a live format (compared with the traditional case-based approach used widely in IT education).
In Phase 2, students must prepare to present a first proposal to the customer.During this three week phase, they elaborate their solution, and prepare a convincing presentation to the customer.After presentating, the customer provides their feedback.In many cases, this is an opportunity for the students to clarify their understanding of the mandate.
In Phase 3, building on the customer's comments, the teams must prepare an answer to the RFP as well as a working prototype.Student teams are time-constrained as they have three weeks to achieve this delivery.This is where they must use their judgement, and make appropriate scoping choices.In our experience, students need the most coaching and guidance during this period.As they get closer to the deadline, the decision to reduce the scope of the working prototype gets more and more difficult.Students must also prepare a convincing document and refined presentation for final presentation on Week 11.
Phase 4 is the project post-mortem, which is performed on Week 12.We debrief the students about their experience.At this point, the competitive nature of the project is irrelevant.Students can talk openly about the problems they have been facing and can also propose ideas to improve this course.In preparation for the customer visit, teams analyse the AS-IS described in the RFP.Teams must prepare a list of questions for the client to further elicit the business problem.
3 Customer visit The "real" customer comes to visit the student teams.Each team is allowed a fixed amount of time in order to interview the customer representative.At the end of the class, the students should be able to validate their understanding of the mandate with the customer.Students present their proposed blueprint to the "real" customer.This meeting provides students with the opportunity to get initial feedback from the customer relevant to the proposed solution.
Phase 3 8 Final testing Over the next three weeks, students must develop a working "prototype" based on their proposed solution.Given the time constraint, teams must make scoping choices needed to meet the final presentation deadline.9 10 11 Final presentation A final presentation is organized with the "real" customer.During this presentation, each team must convince the customer that they have the most effective solution to answer the RFP During this presentation, students must use their communication skills to convince the customer.They must also demonstrate their prototype.

Post mortem
The last week of the course is used to do a post mortem of the project and the course.

Conclusion
It was aimed, in this paper, to explore the learning process of IT students while being interested in developing their ability to perform project scope management.We presented and discussed a novel course curriculum, implying a coherent teaching approach which we believe can maximize students learning in project management training.We described how the proposed approach was used in class, and analyzed the observed outcome from our limited experience.
We believe that the framing with the RFP is a very effective vehicle -it allows retention of the richness and complexity of the business problems, while constraining the scope for academic purposes.There is no failure if the solution is too simplistic or not robust.What is important for students is to sell the value of their solution and their ability to execute the proposed project.The competitive nature of the RFP also brings excitement and stress of a kind often unexplored in academia but typical once they enter industry.
Our future intention is to extend and replicate this approach for additional courses.On-going research aims to gather empirical evidence in order to measure the effectiveness of our training strategy.Investigation of industry expectations of new hires, and degree of fit, between the ZPD guidance and assistance concept with that of supervision and mentoring, could also provide valuable insight.
three weeks, students develop the blueprint of a TO-BE solution for the customer.Students are given access to SAP best practices (www.sap.com/bestpractices) to build their solutions on top of the existing technology

Table 1 .
Course Curriculum IntroductionThe RFP is presented to the students."Balanced teams" are put together, taking into account the technical and communication skills of students.