Project Scope Statement

The project scope statement is similar but more detailed to the project charter, it defines the objectives and deliverables of the project.

Project Charter

Project Scope Statement

Project purpose or justification Measurable project objectives and related success criteria High-level requirements High-level project description High-level risks Summary milestone schedule Summary budget Stakeholder list Project approval requirements (what constitutes success, who decides it, who signs off) Assigned project manager, responsibility, and authority level Name and authority of the sponsor or other person(s) authorizing the project charter

Project scope description (progressively elaborated) Acceptance criteria Project deliverables Project exclusions Project constraints Project assumptions

as we further define the details of the project these details mature and more accurately represent the scope of work. the project scope statement must be mature enough that the Stakeholders can clearly understand what will be delivered within the project in order for them to confirm that the scope accurately represents the objectives and requirements of the project. Details of on the deliverables that will be produced as well as their acceptance criteria, assumptions and exclusions are also included in the project scope statement.

Project Scope Statement

• Scope Description:
• Narrative Description
• Expected results
• Project Objectives
• Clear & Measurable statements of results and expected benefits of project
• Acceptance Criteria
• Measurable Criteria 
• Used by key stakeholders to provide approval of the objectives & deliverables
• Project Deliverables
• Outputs of the project
• created during
• Planning phase
• Executing phase
• closing phase
• Exclusions
• Not included in the scope of work
• Functions
• Features
• Services 
• Deliverables
• Assumptions
• Criteria or characteristics that are expected to be true about deliverables 
• Constraints
• Limits that are known and must be accommodated 
• Restrictions that are known and must be accommodated 
• Change Management plan
• The process of how changes will be managed
• Project scope
• deliverables 
• requirements 
• Budget
• Schedule
• Changes can be initiated from any stakeholder & must be documented
• Change control board
• team of stakeholders that review & make decisions on changes that will or will not be made to a project.
• Change order from
• Used to document any changes that need to be made to the project
• Version control
• documented history of when and by whom the Project scope statement was approved
• a list of any subsequent agreed to changes approved by the change control board

All project planning documents are live documents that can, and do evolve with the project, this is why all project planning documents require a version control section.

To produce the Project Scope statement, the project charter as well as the project requirements documentation need to be reviewed by the team. The project scope statement provides additional details of what will and will not be included in the project. By explicitly specifying the exclusions of the project it better defines the boundaries of the project scope helping clarify to the stakeholders what is in scope vs what's not in scope. This is very useful during the execution phase of a project and helps protect against scope creep and keep the project within the triple constraint. 

Scope of Work: Collecting Requirements

To fully understand the scope of work not only must we understand the final deliverable but we must also understand all of the incremental deliveries along the way to the project completion. Collecting requirements starts in the initiation phase with the project charter, however the requirements in the project charter are a starting point.

All stakeholder input is required for requirements collection, this can be done in a one to one bases but it is preferred to bring all of the stake holders together for a group requirements gathering session. This group requirements gathering sessions provides three benefits:

• Collects requirements for the project plan
• Gives stakeholders a common understanding of the requirements 
• Resolves competing and/or conflicting requirements

Requirements must support the project objectives, the Project Manager must ensure that at all times the requirements support and do not conflict with the project objectives; it is also important to ensure that the requirements are feasible. Requirements define what needs to be done and not how.

Requirements will generally fall into the following list:

• Product technical or functional requirements  
• Project  process/management requirements 
• Quality or performance requirements (for the project and product)
• Business or organizational requirements (for the project and product)
• Support or operational requirements (for the product)
• Profitability or sales/Marketing requirements (for the product)

Documenting Requirements
All requirements are collected, documented, reviewed, prioritized and approved by the stakeholders. these requirements are the basis from which the work activities/tasks are defined. These requirements are often documented in a "Requirements Tractability Matrix"; it's a grid that links product requirements from their origin to the deliverables that satisfy them.

Requirements map directly to deliverables or objectives, each requirement must support an objective or deliverable directly. If a requirement doesn't support an objective or deliverable then there is a problem that needs to be addressed, either you're missing an objective/deliverable, or the requirement is not valid.

The main deliverable is comprised of smaller ancillary deliverables that build up to support the project purpose and objectives; the main deliverable, the successful completion of the project.

Requirements should be traceable to deliverables which in turn support the Project Objectives. in this way requirements are connected to work items that produce deliverables which support objectives.

Requirements need to be measurable and testable to show the customer that they where successfully completed as defined in the project plan to gain customer approval. All assumptions and limitations should be tracked by the project manager as discussions with stakeholders take place, these items need to be documented in the project scope statement.

Prioritizing Requirements
Not all requirements are of equal importants, some are essential while other a nice to haves. A popular method for prioritizing requirements is the MoSCoW method which breaks requirements down into:

• Must Have: critical have to meet project Objectives
• Should Have: important and should be included in final deliverable if time and budget permits, otherwise need to be delivered at a later date or in a subsequent version.  
• Could Have: nice to have, but the project objective can still be met without these requirements.
• Wont Have: will not be included in the current iteration of the product, these are agreed upon with the stakeholder in the outset of the project that they will not be included, but can be revisited in the future.

Stakeholders need to be involved in the prioritization process of requirements this helps the PM and team understand the most critical requirements that need to be delivered. It is normal to move some requirements to the wont have prioritization as the project plan progresses to facilitate the budget and time restrictions of the project. as the project progress the PM with stakeholder approval can move could have and should have requirements out of scope to deliver the project on time and budget. Since it was decided with the stakeholder that these requirements are not essential to project success getting approval to de-scope them is usually straight forward.

The PM must ensure that the Requirements Traceability matrix is maintained throughout the lifespan of the project to track which requirements are within the scope of the project.

Planning phase

Once we have created a project charter and it's signed off by the stakeholders it's time to start the project plan. The project plan consists of

• Defining the scope of work
• Defining the costs and budget
• Defining the schedule
• Preparing the project plan

The project plan is the road-map for how the objectives laid out in the project charter will be achieved. To begin the project planing phase, first the key personnel with the right skill sets required for the project must be selected, these team members will be leveraged for the planning of the project. The entire team is not necessary, however the key members should have input.

Kickoff or Startup meeting
The purpose of this meeting is to bring the team together, and review the project charter to make sure that everyone understands what the team is expected to deliver and why, if possible the project stakeholders and sponsor should be included; this is an excellent opportunity for the team to start building the interpersonal relationships that are essential for a project's success.

The kickoff meeting is intended to establish how the team is going to complete the planning phase of the project and may even begin the process. It's perfectly normal for these meetings to last from several hours to several days pending on the complexity of the project. It's not uncommon for project teams to take up to a full week to outline the project plan, by working on the project plan together it gives the team a common understanding of what has to be completed and why.

Defining the scope of work
The first thing that needs to be established in a project plan is the scope of work, the reason for this is because it creates a basis for the schedule of activities and the budget. A budget cannot be defined without knowing the activities and tasks that are required for the successful completion of the objectives. By focusing on the objectives from the get-go the team concentrates their efforts on solving the essential problems and not going off on tangents.

The project's scope defines the project in the terms of deliverables and the work required to produce those deliverables. It is comprised of the work required to manage the project as well as the work required to complete the project, they are two parts of the same whole and their purpose is to successfully deliver the product, service, or resultt. It is essential that the project plan contains all of the work required to fulfill the requirements to deliver the product, service or result because only the work within the scope will be completed.

Developing the Project's Scope requires that we identify the requirements and work for the successful delivery of our product/service/result. the Project scope is comprised of the following:

Project scope

• Requirements documentation
• Scope statement
• Work breakdown Structure (WBS)

Project Charter

• Purpose of the project: a simple business statement about what the project is about
• Objectives: are clear an measurable statements as to the results of the project. When defining Objectives make sure that they meet the SMART criteria
• Specific & clearly stated
• Measurable or Quantifiable
• Achievable
• Relevent
• Time-bound
• Key requirements: List what is needed to achiece the objectives
• Main deliverables (Schedualed milestones): a schedual of what will be deliverd and when
• Resources Required: the things needed to deliver the project succesfully
• Budget
• Personnel
• Equipment
• Materials 
• Major Risks: what could prevent the project from being a success
• Schedule
• Budget
• Profitability 
• Technical
• Organizational
• External
• Key stakeholders & sponsers: people who are affected by the project and people who have influence over the project, at a minimum this will be the sponsor, the clients and the team. 
• Project Sign off: this is where the project signed off by the sponsor and PM and client

Project Initiation

Once a project is selected it must be initiated, it is in this phase that the project manager learns:

• The objectives of the project
• The business reasons as to why the project was selected
• Information about the project deliverables, Timeline, and budget
• Gains approval to proceed with the project

The initiation phase of a project lays the groundwork for the project

• defines the reasons why they project is undertaken
• the primary business benefits of the project
• the goals the project is expected to achieve
• ensures that all stakeholders are on the same page
• acknowledgment by management of resources required: time, budget, scope
• Project Charter (main deliverable)

Once a project has been added to the project portfolio the organization assigns a project manager to it. The main deliverable of the initiation phase of a project is the charter, the project charter defines:

• Purpose of the project: a simple business statement about what the project is about
• Objectives: are clear an measurable statements as to the results of the project. When defining Objectives make sure that they meet the SMART criteria
• Specific & clearly stated
• Measurable or Quantifiable
• Achievable
• Relevent
• Time-bound
• Key requirements: List what is needed to achiece the objectives
• Main deliverables (Schedualed milestones): a schedual of what will be deliverd and when
• Resources Required: the things needed to deliver the project succesfully
• Budget
• Personnel
• Equipment
• Materials 
• Major Risks: what could prevent the project from being a success
• Schedule
• Budget
• Profitability 
• Technical
• Organizational
• External
• Key stakeholders & sponsers: people who are affected by the project and people who have influence over the project, at a minimum this will be the sponsor, the clients and the team. 
• Project Sign off: this is where the project signed off by the sponsor and PM and client

Stakeholders & Sponsors

Stakeholders 

Not all stakeholders have equal amounts of power or interest in a project, typically the two groups to focus your energy on are whoever is paying for the project, and the personnel who will be using the system.

It's fairly obvious that a you should establish a close relationship with all stakeholders on a project but most importantly those with power and interest, managing their expectations and interests is one of the main keys to a successful delivery.

Not only should stakeholders be identified in the Project charter, but they should also review and sign off on it, to ensure that everyone is on the same page as to what the objectives and deliverables are.

the expectations & requirements of all stakeholders along with their roles & responsibilities must be captured.

Project Sponsors

The project sponsor is usually a management level executive who is championing the project, it is this champion who's identified the financial and non financial benefits of the project and guided it into the project portfolio. This champion usually has a vested interest in the project and thus will be the main source of support for the PM. Usually the Project sponsor is the main stakeholder, the budget is provided by them they are where to go when resources are needed and often times the deciding factor as to what is being built.

The Project Organization

Different organizations have different structures, these differences in organization structure will translate into the organization of a project.

three types of organizational structures are

Functional: also known as traditional, hierarchical or vertical.

Organizations that utilize the Functional structure have a clear chain of command, typically if a project resides inside of a functional unit for example HR, that PM will generally report to the functional head and build the majority of their team from within that functional unit.

Pro's	Con's
Simple	Coordination between functions can be difficult
Direct Access to technical resources	Project can take a back seat to operations
Team members report to their boss

this structure is best when the project is contained within one functional area, since as a PM you'll be reporting to a functional head who's in charge of the personnel, money and scope you'll have very little power, you'll be more of a project coordinator than manager. You'll also be competing against operational priorities for resources. In this type of structure you'll have to rely heavily on soft skills to get what you need to be successful.

Pure Project Organization
this is the opposite of the functional organization, in the projectized organization the PM is the boss, is responsible for time, resources and scope. The personnel are 100% allocated to the project, the PM has full authority. In organizations that utilize the pure project approach to organization every endevour is temporary. Project work isn't organized by function but is rather allocated to a group of resources that come together to solve that particular unique problem.
In such an organization all of the team members report directly to the PM, and only work on their current project deliverables; this type of approach is ideal for multi year projects that require a dedicated team to solve a complex problem.

Pro's	Con's
PM has full authority, all members report to PM	Temporary all good things must come to an end
Simple structure don't have to negotiate for resources	Resources can't be shared, must keep team busy
Direct access to permanent resources allocated to your project	can create duplication
strong team identity and commitment, bonds form between colleagues

Matrix Organization
This organization structure tries to leverage the Pro's of both the functional and pure project organizations. In a matrix organization there are traditional functional units, but the projects will draw members from these functional units, but unlike the functional organization structure the resources are shared by the PM and the functional head, meaning that they have two bosses. Matrix organizations come in multiple flavors, ones that are considered weak will take on more of the traditional functional organization attributes whereas ones that are considered strong matrix organizations will take on more of the characteristics of the pure project organization.

the distinction of whether a matrix organization is considered

• Weak: functional head controls resources
• Balanced: functional head and PM share responsibility of resources
• Strong: PM controls resources

Pro's	Con's
Shared & flexible access to resources	Employees have two Bosses
Resources are project focused	Increased Conflict, employees have to balance operational with project work
Shared commitment between PM and functional head	Communication complexity

As you can see none of these approaches are perfect the trick is to pick the approach that best fits the particular project.

Project length: for projects that are cross-functional and run multiple years the preferred structure is pure project or strong matrix.

# of functional areas needed: when numerous functional areas are required to complete a project than the more valuable it is to use a strong matrix or pure project approach.

Functional knowledge is key: when the project is within a functional unit and the knowledge is very niche than a functional organization may be best suited.

Project Selection

Organizations generally don't have enough resources (people or money) to complete every project they'd like to, thus what they need to do is pick the projects that will have the highest Return on investment. The collection of projects that an organization considers key to it's success is referred to as a project-portfolio; this project-portfolio is a collection of projects that can realistically be completed in a timely fashion and help the organization achieve it's strategic goals, which are high level goals to benefit the company in the grand scheme.

Organizations generally have limited resources, more often than not they don't have enough resources to realistically complete every project they'd like to and thus they need some sort of logical way to select projects with the highest ROI; here are three financial selection processes:

Payback Period
This approach is a simple calculation: Payback period = (Initial investment)/(Periodic cash flow) this means that if our project cost $100 and our projected returns where $20 a year it would take 5 years for this project to break even on the investment, after that the project would begin to generate revenue for the organization. The downside of this approach is that it doesn't factor in the time value of money, meaning that because of inflation a $100 investment today is worth less in 5 years.

Net present value
Is a fairly straightforward calculation where
NPV = sum((ROI per year)/(1+discount value)^(Year Count)) - initial investment

so that means that if your project has an initial investment of $100
a projected ROI for year 1 of $20
a projected ROI for year 2 of $10
a projected ROI for year 3 of $25
a projected ROI for year 4 of $30
and a discount rate of 10%

npv = (20/(1+0.1)^1) + 10/(1+0.1)^2 + 25/(1+0.1)^3 + 30/(1+0.1)^4 - 100

npv = 20/1.1^1 + 10/1.1^2 + 25/1.1^3 + 30/1.1^4 - 100

npv = 20/1.1 + 10/1.21 + 25/1.331 + 30/ 1.4641 - 100

npv = 18.18 + 8.26 + 18.78 + 20.49 -100

npv = 65.71 - 100

npv = -34.29

NPV of 0: project will make enough money to meet the organizations needs
NPV of positive:project will surpass the requirements of the organization
NPV of Negative: project will fall short of the organizations requirements

Profitability index
is a simple ratio
PI = present value of future cash flows/Initial investment,

>1: financial benefits to organization
<1: financial drain to organization also the NPV will be 0.

these calculations are only as good as their estimates.

Numbers are great but sometimes cold hard numbers are trumped by non-financial criteria such as

• Legal requirements: to meet the requirements of a new law
• Competitive advantage: to beat the competition to market for example
• new tech or process: to facilitate earnings in the future.

organization use a combination of financial and non financial criteria to select projects for their portfolio. a typical project selection process maybe something like

1. Business plan identifies project opportunities aligned to the organization's strategy or an employee has an idea for a project and reviews it with their management team for concurrence to proceed and get allocated funding. 
2. Management submits project information on a standardized form. This form typically includes basic level business criteria such as the project goals and deliverables, project purpose, the business reason or business problem addressed by the project, and general information about the project cash outflow, inflow, and market potential. 
3. Project Portfolio team reviews the project suggestions and pre-selects projects based on a set of criteria that best matches the strategic plans of the organization. 
4. Projects undergo additional feasibility studies to confirm viability and confirm the financial and non-financial benefits. This typically includes a review of the project resource requirements. 
5. A final set of projects is prioritized and selected with Project Managers assigned to begin Project Initiation.

organizations will generally stick to their project selection process and not deviate from it. while reviewing the projects in their portfolio trying to ensure that only high value projects are committed to because the more projects an organization is committed to the fewer resources can be allocated to each and thus diluting the value added.

Project Management Office

The Project Management Office(PMO) or just Project Office (PO) is an internal unit that is sometimes set up by organizations to help facilitate project management. They're function is to increase the project success ration by providing support to projects and project managers.

The PMO can provide a wide variety for services

• Be responsible and support the organizations Project Management methodologies and processes.
• Provide Project management expertise and training
• Project auditing
• Support Organizations project management tools.
• Serve as a repository for Best practices 
• Provide standards for collecting project KPI's as well as reporting and measuring project progress
• Facilitate project reviews: lessons learned.
• Help allocate resources across multiple projects.
• Assist with project selection and Project portfolio management. 

PMO's often try to standardize the Project management approach within an organization, keep all PM's using constant PM techniques, tools, and processes. PMO's are responsible to support projects and project managers doing what they can to help increase the success rates of projects.