Project Management Issue: Not Being Specific with the Project Scope

Introduction

PUPQC - 1

Project Management Issue: Not Being Specific with the Project Scope Introduction

Having a project is not only part of the college life but in a real world as well outside the university. In school, we encountered many difficulties when dealing and accomplishing a project even it is a development or research or both, and the thing that we commonly experienced or stock with is the scope of our projects. We often questioned about the scope of our projects, and sometimes the scope of our projects in the proposal become different when we accomplished the project. Project scope is one of the most important parts in project management because it is the part of accomplishing our projects where we always depend on. It is the part of our project management where we depends our project planning on how we will divide our task to make it. Though it is normal for parts of the project change along the way, however the better the project has been scoped in the beginning the better. Being a student who already handled many projects in different subjects, I shall say that determining the project scope is the crucial part of project development. Starting from the proposal, planning and accomplishing, scope change along the way. Sometimes the project scope is hard to defend because its changing and sometimes become bigger at the end. This research entitled Project Management Issue: Not Being Specific with the Scope of the Project will focus on how it becomes an issue and what are the common tips to deal with our project scope along our project development.

PUPQC - 2

Project Management Issue: Not Being Specific with the Project Scope Objectives

To learn the current issues and problems about project scope. To learn some techniques and method about dealing a project scope. To learn how scope affects the project management. To give recommendations for the future researchers related to the project scope in project management.

Issues Having a specific scope in the project enables you to use all the following capabilities:

Effectively manage the resources, time and money in a project unless you actively manage the project scope.

When the project is about to be funded, there should be a set of defined deliveries and objectives for the project. There can be a high level-scope statement prepared at this level.

The defined scope of the project usually included into the contractual agreements between the client and the service provider.

Collect the requirements for the project based on the stakeholders' needs, which will determine the project scope.

Develop the description for the project and its products, which is the basis for the project scope.

PUPQC - 3

Project Management Issue: Not Being Specific with the Project Scope Ensure that the boundary between this project and other projects and programs is clearly understood and prevents gaps or overlaps in all the work that is necessary to achieve higher-level objectives. Ensure that the work that the project must do, and what it is specifically excluded from doing, are defined and agreed by interested parties. Create a baseline for subsequent change control so that the damaging effects of Scope creep can be minimized. A scope that is not collaborating leads to misinterpretations in requirements and design. To avoid this, the scope document should be shared with all stakeholders. Ambiguity in scope leads to confusion and unnecessary work. To avoid this, the scope needs to be clear and to the point.

These issues are not related to what we do but rather, what we dont do. It all begins with how organizations define business processes. When I asked these questions I usually get answers like its a set of activities that ta ke inputs and produce outcomes. There are two characteristics of process that rarely, if ever, get mentioned. First, almost all processes are cross-functional. Second, almost all processes connect or interface with other processes. So, if your project encompasses a process that is contained within one functional area, theres a very good chance that youre original project scope only encompasses a portion of the process but eventually it will encompass the entire process.

PUPQC - 4

Project Management Issue: Not Being Specific with the Project Scope

The purpose of defining scope is to clearly describe and gain agreement on the logical boundaries of your project. Scope statements are used to define what is within the boundaries of the project and what is outside those boundaries. The more aspects of scope you can identify, the better off your project will be.

Scope The scope and focus of this study is about having a specific project scope in a project management.

Terms

Cross - functional are processes that span across several different departments of one business.

Describes an approach to integrating operational processes into crossfunctional customer focused view for improved customer relationship management

Project Scope the part of project planning that involves determining and documenting a list of specific project goals, deliverables, tasks, costs and deadlines.

PUPQC - 5

Project Management Issue: Not Being Specific with the Project Scope what the project is supposed to accomplish and the budget of both time and money that has been created to achieve these objectives. Project Management the discipline of planning, organizing, motivating, and controlling resources to achieve specific goals typically involves a one-time project rather than an ongoing activity, and resources managed include both human and financial capital. Scope Creep refers to a project that has seen its original goals expand while it's in progress. As the term suggests, scope creep is a subtle process that starts with small adjustments and ends up resulting in projects that take far longer to complete or even fail before they are finished. Even if the project is completed, scope creep can result in final deliverables that look nothing like what was originally envisioned. Scope Statement may take many forms depending on the type of project being implemented and the nature of the organization. The scope statement details the project deliverables and describes the major objectives. The objectives should include measurable success criteria for the project.

PUPQC - 6

Project Management Issue: Not Being Specific with the Project Scope

Related Studies

PUPQC - 7

Project Management Issue: Not Being Specific with the Project Scope Related Studies

Not being specific with the project scope is a common issue when handling or dealing with a project. It is commonly the project part where we questioned often. It is sometimes bring big problem if you dont understand what really the scope of your project is, and the most d ifficulty we really dont want to encounter is when our project scope become bigger and bigger along the project development that sometimes lead us to project ambiguity if we cant able to control it in early time of project development.

According to Jack Howard, a project manager, in his article entitled Taking the Panic Out of Project Change Management, he said that one of the most intimidating moments of his career is when he had to present a change request with significant budget and schedule impacts. It is naturally uncomfortable because he could be asking his sponsor to spend more than they expected to get something later than they wanted. However these kinds of situations dont have to be the panic-inducing frenzy that they often seem to be. He also said that we must focus on these steps to keep the situation under control:

Firmly establish a baseline scope most projects suffer from scope ambiguity, which emasculates your leverage when it comes to dealing with change. The lack of a baseline project scope puts any future change up for interpretation. Define the goals, objectives, characteristics and requirements PUPQC - 8

Project Management Issue: Not Being Specific with the Project Scope for your project and youll have a foundation upon which to manage change. Continue to refine scope throughout the project and reinforce after each major deliverable that a change from the most recent deliverable will result in a change request. Keep asking the simple questions and leave as little as possible to be open to interpretation.

Dont ever say no to change one of the simplest reactions to the stress of project change is to blindly reject it. If a request is out of scope, its possible to think that the responsible thing to do as a project manager is to toe the line and stay true to the baseline scope. However, what if the change is justified and must be addressed to achieve the business objectives of the project? In that case, your rejection of the change is an encumbrance to progress not responsible project management. Also, make sure you acknowledge and communicate that the request is a change to the baseline scope. Long lags between the identification of a scope change and the presentation of the change request never go over well.

Find the root cause of imminent change In many cases, a change request comes in the form of a proposed solution to an undefined problem. A good project manager will assess the cost/schedule impact to that specific change. A great project manager will understand the root cause of that change and begin to establish alternative options to address the driver at hand. Not only does this position you as a project thought leader, but it also

PUPQC - 9

Project Management Issue: Not Being Specific with the Project Scope makes your imminent change request easier to manage because you will be providing your sponsor with options.

Propose alternatives to the stakeholder Nobody wants to be faced with an ultimatum, so dont put your stakeholders in that situation. By now you should have a mature definition of scope and youve gained an understanding of the reason for the requested change. Get your team together and brainstorm options on how to achieve the business objective behind the change. These options will probably include an increase in funding/schedule, cannibalizing existing lower value scope, or deferring the requested change until Phase II. All of your options will have pros and cons, and your sponsor will appreciate the effort the team put in to both solve their problem and keep them out of being backed into a corner.

He also said that as long as all of our change request options keep the project balanced, then we cant lose.

In the article made by Cora Systems entitled Project Scope Management, it stated there that today organizations are facing situations where great ideas get shelved due to their expectations. Project Managers need to be able to show others the expectations and vision project X will bring once completed. Also, it said that as we can envisage, planning is essential in the successful management of projects and this where the project scope management becomes valuable. PUPQC - 10

Project Management Issue: Not Being Specific with the Project Scope

A scope statement is probably the most important document produced for a project however it can be over shadowed and ultimately put on the long finger leading to project creep. The project scope is developed within the initial planning stages of a project and could be looked at as being a blueprint for a project. When fully utilized the project scope details the characteristics of the project once it is completed, this also helps manage the expectations of the project stakeholders to ensure they know exactly what was agreed from the start.

The author also gave a standard process that should be taken on when dealing with project scope so she had laid out a number of steps that could be taken when developing a project scope. They include:

Brainstorming: Conduct a brainstorming session with project stakeholders to gather the project objectives. This will give a clear picture as to why this project should be undertaken.

Requirements: Once the brainstorming has been completed a list of the requirements should be drawn up. All requirements must be identified clearly and obtainable during the project. Any goals or non goals need to be also identified. Non-goals are items that are specifically not going to be addressed during the project; this will help with scope creep.

PUPQC - 11

Project Management Issue: Not Being Specific with the Project Scope Deliverables: Identify the deliverables and if possible link them into specific milestones. Like before these need to be agreed upon by the project stakeholders and any other individual including in the project.

Costs: Include the cost estimates of a project, it is important to be as accurate as possible here. If the estimates are too low, the project is in danger of going over budget and if the estimate is too high, resources that are allocated to the project are held here and not available to other projects.

Signed, sealed and deliver: Once the project manager has assembled all of the necessary elements into one document, all the project stakeholders and owners need to agree with it and sign it off. Having a meeting at this stage would be ideal to clear up any discrepancies and make any final changes

Scope change management: Expectations around cost and time have now been set and agreed upon, however if the deliverables of the project change so may the expectations. This change process must be managed through a well-defined process to ensure that the right decision is made. A few things to keep in mind during this process would be; sponsors approval, communication and impacts of the change.

PUPQC - 12

Project Management Issue: Not Being Specific with the Project Scope As Cora Systems concluded, project scope doesnt always get the time and attention that it needs. More and more the project scope is the most neglected point in the planning phase. However, it can be the most valuable piece of information that you have available to you as it will guide the project in the right direction. Andrea Brockmeier, the author of Manage Scope Change or Let it Creep?, gave four things that should be happen to changes in projects. They should be:

Reviewed Project changes need to be reviewed by the appropriate stakeholder as defined in the change management plan, however formal or informal that may be. Someone needs to understand the change and be able to assess the impact to the project.

Approved Once reviewed, changes need to be approvedor declined. Someone needs to make the decision as to whether or not the change should be included. Either way, an authority defined in the change management plan needs to give the thumbs up or down.

PUPQC - 13

Project Management Issue: Not Being Specific with the Project Scope Documented The decision needs to be documented as does the change itself. All aspects of the project that impacted need to be updated, including the PM plan itself.

Communicated Finally, the change needs to be communicated to all stakeholders per the communications plan. In particular, people in testing, training, or other areas downstream need to be informed so the change can be included in their work on the project.

She also said that the complexity of any of these steps needs to be scaled appropriately and, of course, can be considerable on a large, cross-functional project with stakeholders in many areas. Wherein if a PM does decide to allow for small unmanaged changes, or finds out about a change that somehow got added without much in the way of review or approval, its best to try to range in and get the documentation and communication done as much as possible. Anything to minimize surprises downstream is called for regarding the degree to which changes will be managed.

As Andrea Brockmeier gives the topic about scope creep, Christian Bisson also gives tips to avoid it. Here are those:

PUPQC - 14

Project Management Issue: Not Being Specific with the Project Scope Manage stakeholder expectations This is important, no matter how great what you deliver is, if expectations are above whats delivered, than you will spend all the budget adjusting, and will end with an unsatisfied client. Those adjustments become scope creep and will devastate the budget, the schedule, and potentially the whole project. To manage those expectations, it is important to always be very clear with the client from the start by communicating whats expected to be delivered but dont forget to discuss whats excluded too. Another little tip is to not be afraid to say No!

Change management process It is important to know what the process is when you think a scope creep is coming up. Do you have to talk to an account manager? Is there a change management board for the project? Do you have to manage it yourself? Whichever it is, you have to make sure that is clear. Once it is, at least youll know where to start if a scope creep is coming up. Makes it easier! So once a scope creep is on your radar, you can go ahead with talking with the account manager and discuss the battle plan with him, file a change request to the board or you can analyze the impact of the scope creep and talk to the client.

PUPQC - 15

Project Management Issue: Not Being Specific with the Project Scope Communication within the team

Gold plating can add a lot of unplanned costs to your project, and add to your clients expectations, which can have a chain effect throughout your whole project as your client will always expect the gold plating on his project. So to avoid this, you have to clearly communicate the scope to your team. Also, let them know that ideas are welcome but to discuss them before executing anything. If they communicate their ideas, you can potentially obtain more budget and the client will appreciate the added ideas instead of taking all of it for granted as gold plate.

Mitigation plans

Risks becoming issues are considered scope creep, and the impact can vary from minor to horrible. By planning ahead to avoid anything becoming an issue, you can prevent those scope creep. Its always good to have some budget aside to manage this, but that may not always be possible, so at least keep an eye on those risks, you may use some budget you do not have, but it will still beat those risks becoming issues.

PUPQC - 16

Project Management Issue: Not Being Specific with the Project Scope Though the article made by Andrea Bockmeier and Christian Bisson quite similar, still they both give important and usable tips to avoid the scope creep within our project development.

Another study made by Kathy Long entitled

Managing

Process

Project

Scope, she said that there are some common frustrations of working on process improvement projects such as:

Insufficient resources. Frequently changing definition:

o o o o o

Requirements. Scope. Timeframes. Purpose. Deliverables.

Lack of appropriate management involvement and support. Real 'problem' not identified (symptoms are seen as problems). It's a fire fight.

As listed above scope is there, so she gave seven activities analysts can perform that will significantly reduce changes to a process project's scope. They are:

Accurately define process. Define terms related to the project. Define process boundaries explicitly.

PUPQC - 17

Project Management Issue: Not Being Specific with the Project Scope

Right people defining the scope. Define high level interfaces between processes. Conduct a health check on the process interfaces. Realizing that certain aspects of the project still make it too large to manage.

Wherein, she explained that the accurately define process

is

the

problem that is not related to what we do but rather, what we don't do. It all begins with how organizations define business processes. Most analysts will define process as a set of activities that take inputs and create outputs according to policies, procedures, and rules utilizing people, facilities, and technology. There are variations on the exact wording, but conceptually, this is how most analysts will describe a process. There are two characteristics of process that rarely, if ever, get mentioned. First, all processes are cross functional. Second, all processes connect or interface with other processes. So, if your project encompasses a "process" that is contained within one functional area, there's a very good chance that your original project scope only encompasses a portion of the process however, as a result of discovery, eventually it will encompass the entire process as well as those that having a negative impact on the performance of the process in focus. This is the first Opportunity for scope creep.

The second one is to define terms related to the project, which she said that an analyst must spend time discussing terms related to the project to achieve a

PUPQC - 18

Project Management Issue: Not Being Specific with the Project Scope common definition among all participants and related parties. Most of the time there is an 'assumption' that everyone understands a 'process' in the same way. This is one of the many 'assumptions' that are made surrounding process projects and many of them are not accurate. It means that we assume everyone has a clear understanding of the process and the terms used in the process. When an analyst begins to ask questions, it becomes clear that not everyone is using the same terms to describe the same things. Usually that's when an attempt is made to try to accurately define these terms. Often, this results in a different definition of the project scope as participants realize there are different perspectives of the project.

The third problem according to Kathy Long is the lack of attention given to explicitly defining the start and end points of the process. This is accomplished by defining events that occur in the process and gaining consensus on which of those events is considered to be the starting point and which is the ending point.

The fourth major root cause of process improvement project scope creep is not having the correct participants defining the process. The participants should be high-level managers in the related functional areas who have a very comprehensive understanding of the business and its issues. These must also be the people who have resource allocation authority. If the functional managers are not subject matter experts (SMEs) then we also need these resources as well. Too often the boundaries of a project are defined and then the project goes

PUPQC - 19

Project Management Issue: Not Being Specific with the Project Scope looking for resources and can't find them. When the correct group is defining the scope they are also making resource commitments. Never send someone else to do your job. Fifth, we must define the high level interfaces. Since all processes connect to other processes or stakeholders, it is essential to understand not only where the real problems are but also how large the project must be to fix those problems.

Sixth, we need to analyze all these interfaces to determine the health of each one. Unhealthy interfaces are where a majority of the 'real' process issues can be found. We need to understand what works well, what doesn't, what will be impossible to change or what will just take too much time given our project resource and time constraints.

Finally, according to Kathy Long, an analyst must incorporate realism in the 'project scope'.

Related studies and researches about project scope management only shows that as a project manager, developer, programmer, or simply a member, we must all understand what truly the scope of the project we are doing. By assuring our project scope, we may reduce or lessen the tendency of sudden changes in our project scope and that is the worst thing we dont want to happen, because aside from that our project become bigger, it might also become ambiguous that might lead us to slow project accomplishments.

PUPQC - 20

Project Management Issue: Not Being Specific with the Project Scope

Findings

PUPQC - 21

Project Management Issue: Not Being Specific with the Project Scope Findings

All studies stated in the previous chapter showed how important to have a specific project scope with our project. Properly determining our project scope will help us not only to accomplish our project on time but for us to be able to accomplish a good quality and reliable product.

Sometimes the leading reason why project fails is because of an undetermined project scope. You must make sure that the work you agreed to deliver is completed within the timeframe and budget allocated. Part of the workthe-plan process is preparing for the expected fact that, once the project starts, the client will probably end up asking for more (or different) work than what was originally agreed to. This is when you must use scope-change management. If you dont, you will end up trying to complete more work than what was originally agreed to and budgeted for.

According to the definition of project scope, its purpose of defining scope is to clearly describe and gain agreement on the logical boundaries of your project. Scope statements are used to define what is within the boundaries of the project and what is outside those boundaries. The more aspects of scope you can identify, the better off your project will be. The following types of information can be helpful.

PUPQC - 22

Project Management Issue: Not Being Specific with the Project Scope

The types of deliverables that are in scope and out of scope (business requirements, current state assessment)

The major life-cycle processes that are in scope and out of scope (analysis, design, testing)

The types of data that are in scope and out of scope (financial, sales, employee)

The data sources (or databases) that are in scope and out of scope (billing, general ledger, payroll)

The organizations that are in scope and out of scope (human resources, manufacturing, vendors)

The major functionality that is in scope and out of scope (decision support, data entry, management reporting).

If you cannot accommodate change, the final solution may be less valuable than it should be, or it may, in fact, be unusable. Therefore, you want the client to have the ability to make changes during the project when needed. The problem comes when the project manager does not proactively manage change on the project. Every project should have a process in place to manage change effectively. The process should include identifying the change, determining the business value of the change, determining the impact on the project, and then taking the resulting information to the project sponsor for its evaluation. The sponsor can determine whether the change should be included. If it is included, then the sponsor should also understand the impact on the project and allocate

PUPQC - 23

Project Management Issue: Not Being Specific with the Project Scope the additional budget and time needed to include the change.

Scope changes are probably the major cause of failures according to Jolyon Hallows. He said that the problem with scope changes is not simply that they add cost, but that they add cost out of proportion to their apparent effort. Still, he said that scope changes are a problem for two reasons. Either the project did not clearly establish the scope at the start or the project manager failed to manage scope change requests effectively. Scope changes are inevitable, but they are not necessarily bad-some consulting companies thrive on them. They are detrimental only when they are not properly handled, that is, when they are not adequately defined, tracked, and managed. The second major cause of project failure is poor planning and in particular, overlooking project activities during planning. Such activities are not part of the estimates, they do not appear on the schedule, and they have no effect on the plan. When they do appear, they can cause chaos. For example, a project that needs to train a group of users, but fails to define an activity to create the training materials, will founder and hit delays just when it is about to deliver its benefits.

Thats why Douglas Castle said that projects are generally implemented in stages, and their components are compartmentalized, with each department (or individual) expected to focus on some specific, well-defined scope of responsibilities. When one individual treads out of his or her scope, and into another individuals, this is what Project Managers refer to as scope creep. It

PUPQC - 24

Project Management Issue: Not Being Specific with the Project Scope invariably creates a breakdown in systems, procedures and progress. These can be either prevented or minimized by several means:

Carefully and clearly define the scope of responsibility and principal focus of each project team participant;

Be

certain

that

member

of

the

team

is

coordinating

communications and liaison officer a person through whom any ultra-scope ideas must be presented before being discussed wit h other team members. This tends to discourage creep age, but serves as a means of aggregating (capturing) some ideas which may prove useful; The Project Manager should remind each of the team members of his or her principal focus, scope and function at regular intervals to prevent straying from the planned path, and to minimize the temptations or incentives to chaotic creeping.

A culture of mutual respect and trust amongst the project team should be fostered, and some periodic forum should be devised where team members can creep a bit in the interest of brainstorming and bonding.

PUPQC - 25

Project Management Issue: Not Being Specific with the Project Scope

Conclusion

PUPQC - 26

Project Management Issue: Not Being Specific with the Project Scope Conclusion

As a conclusion, ensuring the right and exact scope of your project is very essential, though there is no perfect project who do not undergo into scope changes along the project development still it is a big help to avoid having a scope creep. Experiencing scope creep means you dont properly determine what your project scope is or the project itself that youre working with.

As Tom Mochil said in his article, project management does not begin and end with defining and planning a project. If you don't invoke scope-change management, your project's success could be in jeopardy. Defining and planning a project is only the first step in successfully managing a project. After you plan the work, you have to work the plan. You must make sure that the work you agreed to deliver is completed within the timeframe and budget allocated. So if along the project development you still dont understand your project scope, I think it is a bit difficult for you to finish your worked on time. Yes you may finish it but it might already meet the deadline and you might also lose many things such as money, time and effort.

Another study that shows how important the project scope is Managing Process Project Scope by Kathy Long, wherein she said that most of an organization's frustration with results from process improvement projects can be

PUPQC - 27

Project Management Issue: Not Being Specific with the Project Scope traced back to the initial work that should've been done at the very beginning of the project:

Accurately define process. Define terms related to the project. Define process boundaries explicitly. Right people defining the scope. Define high level interfaces between processes. Conduct a health check on the process interfaces. Realizing that certain aspects of the project still make it too large to manage.

The advantage in taking the time to go through all these activities is a more accurately-defined project from the perspective of expectations, reduction in the occurrence of unintended consequences, and the ability to measure not only efficiency but also the effectiveness of the changes made to the process. It also ensures that the real problems are being addressed versus the symptoms of the problems. In addition, it saves a great deal of time in the project due to the elimination of rework or redefinition. Also, the resources and timeline are more accurate than any process project that skips any of these activities.

As a student and a researcher as well, planning and preparation for the project development is very important for us to avoid the sudden changes on our

PUPQC - 28

Project Management Issue: Not Being Specific with the Project Scope projects. So defining its project scope properly is a big help to let us know what will be the limit of our project, and for us to understand better what our project really is.

PUPQC - 29

Project Management Issue: Not Being Specific with the Project Scope

Recommendation

PUPQC - 30

Project Management Issue: Not Being Specific with the Project Scope Recommendation

As a proponent who studied and made this research, I would recommend to those next researchers who will make a research related to my study that ensuring and determining the scope of your project at the very beginning of your project development is a big help. It may change along the way but still if you know what is your project scope it will be less difficult for you to handle it and less difficult for you to management all your project changes. Lastly, you may prevent having a scope creep that as Christan Bisson said it is the one of the worst enemy for any PM if not managed properly. It includes anything that was not part of the initial scope of your project and got added without properly going through any processes. One little scope creep may not have much of an impact, but if they stack up, or if one is a major one, the project can severely go over budget, off schedule, or end up.never ending.

As part of the project definition, scope should clearly defined where in sometimes it require more time to define our project scope both in terms of its deliverables and in terms of how it will operate. In defining how the project will operate, the Project Manager should try to influence those factors that could lead to subsequent scope change.

Not all changes follow the approved process. Often team members will be persuaded to make a change without using the approved procedure where it

PUPQC - 31

Project Management Issue: Not Being Specific with the Project Scope seems necessary but minor. Although this can seem practical to those concerned, it represents a risk to the project. The Project Manager and Project Office team should be alert for uncontrolled changes. Where necessary, changes should be painlessly re-directed into the correct procedure.

According to Bhavin Gandhi, if you are not sure about how to move forward with this process then you should at least try to define the deliverables of the project. Dont stress yourself too much. Ask your customers to provide you with tangible deliverables that they would like to see at the end of the project. Once, you figure out the final deliverables of the project, you can then go ahead and try to define the interim project deliverables. These defined deliverables will tremendously help you to better understand the project.

Project boundaries: Once you got some handle on how the project should look like through its deliverables, you should now define how it shouldnt be looking. For example: Chris is going to look for a software third-party provider within the US. In this case, third-party software providers from China are out of scope. If Chris was considering the needs of the entire global company, this would not have been a good boundary statement since he could not have stated a good out-of-scope statement.

Project Features: Once you have described the deliverables and the boundaries, you have completed high-level scope. Now, its time to describe the physical characteristics of the deliverables, called features. If you were building a software framework, for instance, most of the

PUPQC - 32

Project Management Issue: Not Being Specific with the Project Scope functionalities would count as features. These might include the number of GUIs (graphical user interface), number of APIs (application interface), etc. So, follow the top-down approach and start defining projects features from its well defined deliverables. Project Functions: Once you finished describing projects features, now you need to describe how people interact with a deliverable and how a deliverable interacts with other deliverables. For example, if you need to change invoicing and billing transactions, most of the requirements could end up being process oriented. This would include how billing transactions move from orders to invoicing to accounts receivable. Basically you are defining the information flow in this phase. Thus, make sure to involve all the stakeholders, who will be affected by this information.

Bisson and Gandhi both provide tips on how to avoid having scope creep and how we can manage the changes we encountered. They only show how important to us defining our project scope in the early stage of our project development.

PUPQC - 33