effective project management: traditional, agile, extreme
DESCRIPTION
Effective Project Management: Traditional, Agile, Extreme. Managing Complexity in the Face of Uncertainty. Presented by (facilitator name). Ch03: How to Scope a Project. Summary of Chapter 3. Ch03: How to Scope a Project. Managing client expectations Conditions of satisfaction - PowerPoint PPT PresentationTRANSCRIPT
Effective Project Management: Traditional, Agile, Extreme
Presented by(facilitator name)
Managing Complexity in the Face of Uncertainty
Ch03: How to Scope a Project
Managing client expectations Conditions of satisfaction Planning and conducting a project scoping meeting Gathering requirements Diagramming business processes Prototyping your solution Business validation Procurement Management Writing an effective Project Overview Statement (POS) Approval to Plan the Project
Summary of Chapter 3
Ch03: How to Scope a Project
Conditions of Satisfaction Project Scoping Meeting Requirements Gathering Diagramming Business Processes Prototyping Validating Business Cases Procurement Management Outsourcing Project Overview Statement Approval to Plan the Project
Tools, Templates & Processes used to Scope a Project
Ch03: How to Scope a Project
Managing Client Expectations
Somehow clients always seem to expect more than project managers are prepared for or capable of delivering.
This lack of communication starts at the beginning of a project and extends all the way to the end.
The project manager assumes he or she knows what
the client is asking for, and the client assumes the project manager understands what they are asking for.
Client Wants vs. Client Needs Dilemma
What your client wants may not be what your client needs. Your job is to make sure that what they want is what they
need and that you will deliver what they need.
WANTS
NEEDS
Ch03: How to Scope a Project
Client Wants vs. Client Needs Dilemma
The disconnect may come about because the client is swept up in a euphoria over the technology (for example, they may be enamored with what they see on the Web)
The disconnect can also come about because the client does not really know what they need.
Wants tend to be associated with a solution that the client envisions. Needs tend to be associated with the problem.
To be safe, always ask the client why they want what they want.
Conducting Conditions of Satisfaction
You should begin every project with a communications tool called Conditions of Satisfaction (COS).
The COS is a structured conversation between the
client (the requestor) and the likely project manager (the provider).
The deliverable from the COS is a one-page document (with attachments) called the Project Overview Statement (POS).
Conducting Conditions of Satisfaction…
The POS is a template that is used to clearly state what is to be done.
It is signed by the requestor and the provider who participated in the COS exercise.
When the POS is approved by senior management, the Scoping Phase is complete.
Conducting Conditions of Satisfaction…
The process of developing the COS involves the following four parts:
1. Request. A request is made. 2. Clarification. The provider explains what he or she
heard as the request. 3. Response. The provider states what he or she is
capable of doing to satisfy the request. 4. Agreement. The requestor restates what he or she
understands the provider will provide. The conversation continues until the provider is satisfied that the requestor clearly understands what is being provided.
Establishing Clarity of Purpose
The next step in the COS process is to negotiate to closure on exactly what will be done to meet the request. Obviously, some type of compromise will be negotiated.
The final agreement is documented in the POS.
As shown in Figure 3-1, this process repeats itself until there is an agreed-on request that is satisfied by an agreed-on response.
Establishing Clarity of Purpose
As part of this agreement, the POS should include a statement of success criteria that specifies when and how the request will be satisfied.
The success criteria will become part of the POS.
The result is documented as the COS and serves as input to the POS.
This early step of establishing and agreeing to what will be done is very important to the project’s success.
Establishing Conditions of Satisfaction
Negotiate agreement andwrite Project Overview Statement
Request Response
ClarifyRequest
Agree onResponse
Ch03: How to Scope a Project
Figure03-01
Specifying Business Outcomes
it is a good idea to specify within the COS exactly what outcomes demonstrate that the COS has been met. The outcomes have been called success criteria
it is a quantitative measure (for example, profit, cost avoidance, and improved service levels) that defines success.
Conducting COS Milestone Reviews
The COS is not a static agreement. It is a dynamic agreement that becomes part of the continual project monitoring process.
Planning and Conducting the Project ScopingMeeting
You may have had a COS session and agreed on a high-level scope for the project but need more detail in order to write a POS.
The Project Scoping Meeting takes the COS
deliverable to the next level of detail.
In this meeting, the core project team will be present, as will the client, several key managers, staff, and end users of the project deliverables.
Purpose Document requirements Project Overview Statement
Attendees Project Manager Client Group Core Team Members The Facilitator & Technographer
Planning and Conducting the Project Scoping Meeting
Ch03: How to Scope a Project
The facilitator group
This group comprises two or three individuals who are experienced in conducting scoping and planning meetings.
The facilitator group will have a meeting facilitator, a requirements gathering facilitator, and a position that the author calls a technographer.
The two facilitators are often the same person. A technographer is the recording secretary for scoping
and planning meetings who has solid experience using a variety of high-tech tools. Larger projects may require two such professionals.
Agenda Introductions Purpose of the Meeting (led by Facilitator) COS (conduct or review if done earlier) Description of current state (led by client representative) Description of problem or business opportunity (led by client
representative) Description of end state (led by client representative) Requirements definition and documentation (led by facilitator) Discussion of the gap between current and end state (led by
project manager) Choose best-fit project management approach to close the
gap (led by project manager) Draft and approve the POS (whole scope planning group) Adjourn
Planning and Conducting the Project Scoping Meeting
Ch03: How to Scope a Project
Deliverables COS Requirements Document Best-fit project management life cycle (PMLC) POS
Planning and Conducting the Project Scoping Meeting
Ch03: How to Scope a Project
Good Client Know what they want Know what it takes to deliver Work towards best solution Easy to work with Meaningfully involved
Who is Our Client?
Not So Good Client Not sure of what they want Constantly change their mind Not interested in solving
project problems Hard to satisfy Not very involved
Project manager & team (PT) must satisfy the needs of both.
Ch03: How to Scope a Project
A requirement is something the product/project shoulddo/produce or a quality that it must have.
What Are Requirements?
Ch03: How to Scope a Project
Different Perspectives on Requirements
How the customer explained it
How the analyst designed it
How the programmer wrote it
How the project leader understood it
How the consultant described it
How the project was documented
What operations installed
How the customer was billed
How it was supported
What the customer really needed
Ch03: How to Scope a Project
Figure03-02
Functional Non-functional Global Product/project constraints
Categories of Requirements
Ch03: How to Scope a Project
Functional requirements specify what the product orservice must do.
Definition: Functional Requirement
Ch03: How to Scope a Project
For example: ‘‘The service shall accept a scheduled time and place for delivery.’’
Non-functional requirements demonstrate properties that the product or service should have in order to dowhat must be done.
Definition: Non-Functional Requirement
Ch03: How to Scope a Project
These requirements are the characteristics or qualities that make the product or service attractive, usable, fast, or reliable.
For example: ‘‘The product shall have a homemade appearance.’’ or: ‘‘The product shall be packaged so as tobe attractive to senior citizens.’’
Global requirements describe the highest level of requirements within the system or product. They can bethought of as general requirements.
Definition: Global Requirement
Ch03: How to Scope a Project
For Example: ‘‘The system shall run on the existing network.’’ or ‘‘The system must be scalable.’’
Product/project constraints are those requirements that,on the surface, resemble design constraints or projectconstraints.
Definition: Product/Project Constraints
Ch03: How to Scope a Project
Project constraints cover the areas of budget and schedule along with deadlines and so on.
For example: ‘‘The maximum system response time forany client-based transaction must not exceed 4 milliseconds.’’ or ‘‘The total cost plus five-year maintenance must not exceed $35 million.’’
Facilitated Group Session Interview Observation Requirements Reuse Business Process Diagramming Prototyping Use Cases
Approaches to Requirements Gathering
Ch03: How to Scope a Project
Approaches to Requirements Gathering…
Selecting the best methods to generate potential requirements for the project is the responsibility of the project manager, who must evaluate each method for costs, ease of implementation with the client, and risks.
Further, selection of a particular method should be
based on specific product and project needs, as well as proven effectiveness.
Certain methods have been proven effective for specific client groups, industries, and products.
Strengths1. Excellent for cross-functional processes2. Detailed requirements are documented and verified
immediately3. Resolves issues with an impartial facilitator
Facilitated Group Session Method
Risks1. Untrained facilitators can lead to negative responses2. Time and cost of planning and executing can be high
Ch03: How to Scope a Project
Table03-01
Strengths1. End user participation2. High-level description of functions and processes provided
Interview Method
Risks1. Descriptions may differ from actual detailed activities2. Without structure, stakeholders may not know what information
to provide3. Real needs ignored if analyst is prejudiced
Ch03: How to Scope a Project
Table03-01
Strengths1. Specific/complete descriptions of actions provided2. Effective when routine activities are difficult to describe
Observation Method
Risks1. Documenting and videotaping may be time consuming,
expensive and have legal overtones2. Confusing/conflicting information must be clarified3. Misinterpretation of what is observed
Ch03: How to Scope a Project
Table03-01
Strengths1. Requirements quickly generated/refined2. Redundant efforts reduced3. Client satisfaction enhanced by previous proof4. Quality increase5. Reinventing the wheel minimized
Requirements Reuse Method
Risks1. Significant investment to develop archives, maintenance
and library functions2. May violate intellectual rights of previous owner3. Similarity may be misunderstood
Ch03: How to Scope a Project
Table03-01
Strengths1. Excellent for cross-functional processes2. Visual communications3. Verification of “what is/what is not”
Business Process Diagramming
Risks1. Implementation of improvement is dependent on an
organization being open to changes2. Good facilitation, data gathering and interpretation
required3. Time-consuming
Ch03: How to Scope a Project
Table03-01
Strengths1. Innovative ideas can be generated2. Users clarify what they want 3. Users identify requirements that may be missed4. Client–focused5. Early proof of concept6. Stimulates thought process
Prototyping
Risks1. Client may want to implement prototype2. Difficult to know when to stop3. Specialized skills required4. Absence of documentation
Ch03: How to Scope a Project
Table03-01
Strengths1. State of system described before entering the system2. Completed scenarios used to describe state of system3. Normal flow of event/exceptions revealed4. Improved client satisfaction and design.
Use Case Scenarios
Risks1. Newness has resulted in some inconsistencies2. Information may still be missing from scenario
description3. Long interaction required4. Training expensive
Ch03: How to Scope a Project
Table03-01
Building the Requirements Breakdown Structure
Ch03: How to Scope a Project
Figure03-03
Project goaland solution
Requirement 1
Function1.1
Feature1.2.1.1
Featuren.3.1
Sub-function1.2.3
Requirement n
Function1.2
Function1.3
Functionn.1
Functionn.2
Functionn.3
Sub-function1.2.2
Sub-function1.2.1
Featuren.3.2
Featuren.3.3
Featuren.3.4
Feature1.2.1.2
Feature1.2.1.3
Feature1.2.1.4
Building the Requirements Breakdown Structure
The RBS is a hierarchical description of what the solution has to do in order to acceptably meet client needs.
Project goaland solution
Requirement 1
Function1.1
Feature1.2.1.1
Featuren.3.1
Sub-function1.2.3
Requirement n
Function1.2
Function1.3
Functionn.1
Functionn.2
Functionn.3
Sub-function1.2.2
Sub-function1.2.1
Featuren.3.2
Featuren.3.3
Featuren.3.4
Feature1.2.1.2
Feature1.2.1.3
Feature1.2.1.4
RBS – The Reality
Ch03: How to Scope a Project
FunctionalRequireme
nt n
The RBS is intuitive and most meaningful to the client
The RBS is a deliverables based approach The RBS is consistent with the PMI PMBOK The RBS remains client facing as long as possible
into the planning exercise
Characteristics of the RBS
Ch03: How to Scope a Project
Does not require a trained facilitator Does not require learning one of the contemporary approaches
to requirements gathering Presents an intuitive approach to gathering requirements Allows the client to work with the project team in an
environment familiar to them, i.e., to stay in their own comfort zone
Paints a clear picture of the degree to which the solution is clearly defined
Provides the input needed to choose the best fit PMLC Model
Advantages of using the RBS
Ch03: How to Scope a Project
A business process is a collection of activities that takeone or more inputs from one or more different sourcesand produces a change of state that delivers businessvalue.
What is a Business Process?
Changeof state
Business Process
Input B
Input C
Input A
Ch03: How to Scope a Project
Figure03-04
Creating a Business Process Diagram
Ch03: How to Scope a Project
Figure03-05
Creating a Business Process Diagram….
Operation— Denotes that a change has taken place. The input is somehow changed as a result of having gone through this process.
Movement —Denotes the movement of output from one process step to become the input to the next process step.
Decision —Denotes that a question needs to be answered. There are two flow paths that emanate from a decision box: Yes or True and No or False. You follow one of these paths based on the decision.
Inspection— Someone other than the person producing the output must inspect it for quality, conformance, or some other tangible characteristic.
Creating a Business Process Diagram….
Document—Denotes a paper document.
Delay —Denotes a wait state in a process. It’s usually associated with something joining a queue and waiting for the operator of the next process step to become available.
Storage— Indicates that an item has been placed in storage and must wait for a release before moving to the next process step. This usually represents wasted time that must be removed from a process.
Creating a Business Process Diagram….
Annotation—Provides added detail about some process, which is needed for clarification. It might also include the position title of the person responsible for the process.
Direction of Flow — Denotes the order of process steps.
Transmission —The interrupted arrow indicates when information is to be transmitted from one physical or virtual location to another.
Creating a Business Process Diagram….
Connector— Connects the flow between two separate locations; often used as an off-page connector.
Boundaries— Denotes the initiating and closing processes of a flow diagram. Usually the words START or BEGIN are associated with the initiating process, and STOP or END with the closing process.
Business Process Diagram Formats
Three common formats are used: The top-down and left-to-right format: It is commonly used
in program and system flow charts.
‘‘Swim-lane’’ format: It identifies the actors who participate in the business
Context Diagrams: One way to describe your process at a very high level
The Top-Down Left to Right Format
Ch03: How to Scope a Project
Figure03-06
The Swim Lane Format
Ch03: How to Scope a Project
Figure03-07
Context Diagramming Process
Ch03: How to Scope a Project
Figure03-08
Context Diagrams
Describes a rough process or a set of processes. It generally has only the following few components:
A stick figure representing the external entity that is triggering the process
A large circle representing the organization responding to the request
A text block showing each organization or process acting to fulfill the request
Arrows showing the rough flow between text blocks
Prototyping Your Solution
Many clients cannot relate to a narrative description of a system but they can relate to a visual representation of that system.
Its original purpose was to help clients define what they wanted.
By showing them a mock-up of a solution, they could comment on it and give the developers more insight into what constitutes an acceptable solution.
Use Cases
Figure 3-9 depicts the position of use cases in the overall project scoping.
Use Cases…
Project scoping can be part of the Scoping Process Group or Planning Process Group.
In Figure 3-9, project scoping is between the Scoping Process Group, which has the POS as output, and the Planning Process Group.
Requirements gathering consists of several different approaches of which use cases is but one.
After the use cases have been defined and documented, a single requirements document is assembled, and the project can move to the approval stage or, if the approval stage has already been reached, to the Planning Phase.
Use Case Diagrams
A use case diagram is a simple way to describe how an individual interacts with a business process.
It consists of one of more stick figures (the actors), ovals (the process steps), and connecting arrows (the interactions)
An actor initiates the use case by interacting directly with the system. The system gathers information from the actor, processes it, and returns a result to the actor.
Use Case Flow of Events
This document reads like the script in a play.
It is initiated with an action by the primary actor, the system responds, the actor takes another action, and this back and forth exchange continues until the use case ends.
Validating the Business Case
A very important question will be, ‘‘Does the resulting business value exceed the total cost of the deliverables?’’
You can expect to provide any number of financial analyses such as cost/benefit, Return on Investment (ROI), breakeven, and cash flow analyses, among others.
Some of these might accompany the POS.
Use Case Diagram
You do not have the necessary skills and competencies on your staff Buying the solution is less costly and more effective than building the solution There is a commercial product available that will meet your needs It is more cost effective to have a specialist provide the service It is not part of your core business activity You would like to develop the skills by first using a contractor
Outsourcing to Vendors and Contractors
Ch03: How to Scope a Project
Procurement Management – The Life Cycle
VendorSolicitation
VendorSelection
Ch02: Project Life Cycle Processes
Procurement Management Life Cycle
VendorSolicitation
VendorEvaluation
VendorSelection
VendorManagement
VendorContracting
Publish Request for Information (RFI) Advertise Rent a targeted list Include previous vendors Attend a trade show where potential vendors are likely to have a booth Preparing and Distributing a Request for Proposal Manage RFP responses and questions
Respond online Answer questions individually Hold a bidders conference
Ch02: Project Life Cycle Processes
Preparing and Distributing a Request for Proposal
You need to state the time conditions for response, which means that you state how many days you will give people to respond, as
well as how long you will need to review the responses
before making a choice.
RFP
RFP should contain the following: Introduction Business profile Problem or opportunity POS (optional) RBS (optional) Vendor responsibility Contract administration Instructions to vendors Vendor point of contact Time and cost estimates Pricing Evaluation criteria
Procurement Management Life Cycle
VendorSolicitation
VendorEvaluation
VendorSelection
VendorManagement
VendorContracting
Establish Vendor Evaluation Criteria Evaluate responses to RFP
Reduce list of companiesConduct onsite presentations
Ch02: Project Life Cycle Processes
Vendor evaluation consists of creating a rule by which all RFP responses are evaluated on the same scale.
Establish Vendor Evaluation Criteria
an evaluation team is involved
criteria that ‘‘might’’ be necessary should be eliminated.
Criteria might be classified as ‘‘must have,’’ ‘‘should have,’’ or ‘‘it would be nice to have,’’
There are several quantitative models for evaluating and ranking vendors such as: Forced Ranking, and Paired Comparisons
Establish Vendor Evaluation Criteria
There are several qualitative factors that might be used. They include the following:
Corporate experience with similar work Financial stability Technical approach Personnel experience, skills, and competencies Risk management processes Location Applicable tools, templates, and processes References for similar work
Evaluation Criteria – Forced Ranking
Ch03: How to Scope a Project
Consultant
Vendor
A B C D RankSum
ForcedRank
1 2 3 2 4 11 3
2 4 1 1 2 8 1
3 6 2 5 5 18 5
4 1 5 3 1 10 2
5 3 4 4 3 14 4
6 5 6 6 6 23 6
Table03-02
Evaluation Criteria – Paired Comparisons
Ch03: How to Scope a Project
1 2 3 4 5 6 SUM RANK
1 X 1 1 0 1 1 4 2
2 0 X 1 0 1 1 3 3
3 0 0 X 0 0 1 1 5
4 1 1 1 X 1 1 5 1
5 0 0 1 0 X 1 2 4
6 0 0 0 0 0 X 0 6
Table03-03
Procurement Management Life Cycle
VendorSolicitation
VendorEvaluation
VendorSelection
VendorManagement
VendorContracting
Select the final vendor(s)
Ch02: Project Life Cycle Processes
Procurement Management Life Cycle
VendorSolicitation
VendorEvaluation
VendorSelection
VendorManagement
VendorContracting
Negotiate the final contract No award Single award Multiple awards
Contract Managementdeliverable datesWBSRegular status meetings
Types of Contracts Fixed Price Time and Materials Retainer Cost Plus
Discussion points for negotiating final contract Final negotiation of contract
Ch02: Project Life Cycle Processes
Discussion Points for Negotiating the Final Contract
Work schedule Payment schedule Fees Personnel assigned to the contract Rights in data Other terms and conditions Ownership Warranties Cancellation terms
Final Contract Negotiation
Statement of work for the vendor Terms and conditions List of deliverables, schedule, and budget Defined acceptance process, including acceptance criteria Identification of the project and supplier representatives
responsible and authorized to agree to changes to the vendor agreement
Description of the process for handling requirements change requests from either side
The processes, procedures, guidelines, methods, templates, and so on that will be followed
Critical dependencies between the project and the vendor
Final Contract Negotiation…
Descriptions of the form, frequency, and depth of project oversight that the vendor can expect from the project, including the evaluation criteria to be used in monitoring the vendor’s performance
Clear definition of the vendor’s responsibilities for ongoing maintenance and support of the acquired products
Identification of the warranty, ownership, and usage rights for the acquired products
Procurement Management Life Cycle
VendorSolicitation
VendorEvaluation
VendorSelection
VendorManagement
VendorContracting
Expectation setting For whom does the vendor work? What is expected of the vendor? What tools and facilities are available to the vendor? What training is available to the vendor? What must the vendor deliver? When must it be produced? Who will receive the deliverables? How will the deliverables be evaluated?
Ch02: Project Life Cycle Processes
Vendor Management
You should make the vendor feel like an equal partner in the project.
That means including them in every team activity
Communication needs to be established early among all relevant stakeholders
Conducting meetings and having face-to-face discussions are the easiest and best ways to set clear expectations and gain a mutual understanding of the requirements and expected performance.
Procurement Management Life Cycle
VendorSolicitation
VendorEvaluation
VendorSelection
VendorManagement
VendorContracting
Monitor Progress and Performance Monitor Requirements Change Requests Monitoring the Performance of Standard Project Activities
Labor hours Cost (Earned Value) Schedule (Earned Value) Frequency of change requests over time Incidence of bugs Risks Issue resolution Staffing levels and changes by position
Transition form Vendor to Client
Ch02: Project Life Cycle Processes
Monitoring the Performance of Standard Project Activities
key metrics need to be provided by the vendor to track actual versus planned contract performance: Labor hours Cost Schedule
Other performance metrics that should be tracked by both the vendor and the project manager include the following: Frequency of change requests over time Incidence of bugs Risks Issues resolution Staffing levels and changes by position type
POS
The POS is a short document (ideally one page) that concisely states what is to be done in the project, why it is to be done, and what business value it will provide to the enterprise when completed.
A general statement of the project A reference for the planning team A decision aid for the project To get management approval to plan the project
Purpose of the Project Overview Statement
POSs
A one-page description that is:
Ch03: How to Scope a Project
POS
The POS can serve other purposes as well Inherited Project
Briefing Tool
Inherited Project
Sometimes you inherit a project. In these instances, the project has been defined and
scoped. A budget, staff resources, and a completion date have also been determined.
In this scenario, do you write a POS? Yes! Why? Two reasons:
to become familiar with and understand the project as well as the client’s and management’s expectations.
the POS will become the referent for the planning team.
Briefing Tool
To give your team briefing information on the project.
Contents of the Project Overview Statement
Ch03: How to Scope a Project
PROJECT OVERVIEWSTATEMENT
Project Name Project No. Project Manager
Problem/Opportunity
Goal
Objectives
Success Criteria
Assumptions, Risks, Obstacles
Prepared By Date Approved By Date
Office Supply Cost Reduction PAUL BEARER
Our cost reduction task force reports that office supply expenses have exceeded budget by anaverage of 4% for each of the last three fiscal years. In addition an across the board budget cut of2% has been announced and there is an inflation rate of 3% estimated for the year.
To implement a cost containment program that will result in office supply expenses being withinbudget by the end of the next fiscal year.
1. Establish a departmental office supply budgeting and control system.2. Implement a central stores for office and copying supplies.3. Standardize the types and brands of office supplies used by the company.4. Increase employee awareness of copying practices that can reduce the cost of meeting their copying needs.
1. The total project cost is less than 4% of the current year office supply budget.2. At least 98% of office supply requests are filled on demand.3. At least 90% of the departments have office supply expenses within budget.4. No department office supply expense exceeds budget by more than 4%.
1. Central stores can be operated at or below the breakeven point.2. Users will be sensitive to and supportive of the cost containment initiatives.3. Equitable office supply budgets can be established.4. Management will be supportive and consistent.5. The existing inventory control system can support the central stores operation.
Olive Branch Del E. Lama9/2/04 9/3/04
Example POS
Ch03: How to Scope a Project
Figure03-11
POS Problem/Opportunity
A problem needing resolution or an untapped business opportunity.
A statement of fact that everyone would agree to. It stands on its own.
This is the foundation on which the proposed project will be based.
Ch03: How to Scope a Project
POS Problem/Opportunity…
Examples of situations that will lead to a statement of the problem or opportunity:
Known Problem or Opportunity Client Request Corporate Initiative. Mandated Requirements
POS Project Goal
A one or two sentence statement of how you intend to address the statedproblem/opportunity.
A scoping statement that bounds the project you are proposing.
Ch03: How to Scope a Project
POS Project Goal
A project has one goal it defines the final deliverable or outcome of the project in
clear terms so that everyone understands what is to be accomplished.
The goal statement must not contain any language or terminology that might not be understandable to anyone having occasion to read it.
the goal statement is short and to the point. you do not control the start date and therefore you cannot
possibly know the end date. Your objective is to postpone giving any fixed duration or completion
date until you have completed the project plan.
POS Project Goal…
S.M.A.R.T. characteristics provide the following criteria for a goal statement:1
Specific—Be specific in targeting an objective. Measurable — Establish measurable indicators of
progress. Assignable— Make the object assignable to one
person for completion. Realistic —State what can realistically be done with
available resources. Time-related — State when the objective can be
achieved—that is, the duration.
POS Project Objectives
5 or 6 brief statements that further bound your project goal statement.
From these statements it is clear what is in and not in the proposed project.
These statements might identify major project deliverables.
These statements form a necessary and sufficient set of objectives.
Ch03: How to Scope a Project
An objective statement should contain the following four parts:
An outcome —A statement of what is to be accomplished.
A time frame —A preliminary estimate of duration. A measure — Metrics that will measure success. An action —How the objective will be met.
POS Project Success Criteria
IRACIS
IR Increase RevenueAC Avoid CostsIS Improve Service
Use quantitative metrics only!How much and by when?
Ch03: How to Scope a Project
Example: This reengineering project is expected to reduce order entry to order fulfillment cycle time by 6 percent.
Technological New to the company Obsolescence
Environmental Management change Staff turnover
Interpersonal Working relationships
Cultural Fit to the company
Causal Relationships Will the solution solve the problem
POS Assumptions, Risks and Obstacles
Ch03: How to Scope a Project
Risk Analysis Financial Analyses
Feasibility studies Cost/benefit analysis Breakeven analysis Return on investment
POS Attachments
Ch03: How to Scope a Project
Expected Review Questions from Management How important is the problem or opportunity to the organization? How is the project related to our CSFs? Does the goal statement related directly to the problem or opportunity? Are the objectives clear representations of the goal statement? Is there sufficient business value as measured by the success criteria to warrant further expenditures on this
project? Is the relationship between the project objectives and the success criteria clearly established? Are the risks too high and the business value too low? Can senior management mitigate the identified risks?
Gaining Approval to Plan the Project
Ch03: How to Scope a Project
Core project team (managers, the professionals, and perhaps the client) Project team (review the POS before submitting it to upper management.) Project manager Resource managers Function/process managers Client Senior management
Participants in the Approval Process
Ch03: How to Scope a Project
Project Approval Status
Senior management may not be ready or willing to give their approval to plan the project: They may reject the proposal out of hand. (based on a
comparison of expected benefits versus total cost coupled with a time frame as to when the benefits will be realized.
They may request a recalibration of the goal and scope of the project followed by a resubmission
They might decide that a later resubmission is in order. (they are not ready to commit to the project at this time)
The approval may be associated with a consideration to add the project to the organization’s project portfolio.