The document discusses project design and management concepts. It covers topics such as project definition, quality assurance, proposals, project start, and project implementation. Key aspects include developing initial project concepts, proposal development, assembling proposals, project initiation, planning, execution, monitoring and control, and closeout. Project roles and phases are also outlined.
3. Project Definition - Find a Client
- Select a Topic
Project
Find Work Quality
- Develop Initial Project
Concepts
Assurance
Proposal Development
Project Implementation
Project Performance,
Monitoring and Closure
4. Getting Started
• Select with a reasonable and manageable scope of work
• Select a reasonably sized project work area
• Know your data requirements and standards
• Know the data available and its quality including metadata
• Know what types of analysis you intend to perform and how
• Determine whether the analysis is static (one time) or
dynamic (repetitive)
• Determine what type of application or tools you could
develop
• Determine if the data or application should be published on
the Web
• Identify the risks and finding contingencies
7. Strengths
• Patents
• Strong brand names
• Good reputation among customers
• Cost advantages from proprietary know-how
• Exclusive access to high grade natural resources
• Favorable access to distribution networks
8. Weaknesses
• Lack of patent protection
• A weak brand name
• Poor reputation among customers
• High cost of structure
• Lack of access to the best natural resources
• Lack of access to key distribution channels
9. Opportunities
• An unfulfilled customer need
• Arrival of new technologies
• Loosening of regulations
• Removal of international trade barriers
10. Threats
• Shift away from the firm's products
• Emergence of substitute products
• New regulations
• Increased trade barriers
11. SWOT Matrix
Strengths Weaknesses
Opportunities S-O Strategies W-O Strategies
opportunities that are a weaknesses to pursue
good fit to the opportunities
companies strengths
Threats S-T Strategies W-T Strategies
identify ways that the establish a defensive plan
firm can use its strengths to prevent the firm's
to reduce its vulnerability weaknesses from making
it highly susceptible to
to external threats
external threats
12. Example Workflow Process Diagram
Enter Camera
Aerial Photo Load MDSD Set-up DEMs and
Calibration Report
Inventory Software DOQQs
Specifications
Digitize Apply AML Tools
Select Point Append Linework
Delineations from to Refine the Final
Registration and Clean
Photos Linework
Create Polygon Create QC Linework and Final Sliver and
Attributes Hardcopies Attribute QC Attribute clean-up
Deliver .e00 files
14. Business Case Development
• Staff responsibilities, tasks performed, and staff structure
• Data used, produced, and maintained in the course of
business activities
• Current use of data, analysis practices, and application
requirements
• Any necessary training to employ your completed MIP at the
client site
15. Data Analysis
• Data Analysis and Inventory
• Conceptual Database Design
• Model the Client's View
• Model the Client's View
• Identify Representations of
Entities
18. Project Origin
• RFP
• RFB / RFQ
• ROM
• Spin-off work (sole-source proposals)
• Unsolicited proposals
• Advertising
• Trade shows
• Personal relationships/contacts
19. Selecting Opportunities
• General Information
• Technical Specifications
• Contract Terms and Conditions
• Proposal Specifications
20. Contract Types
• Firm, Fixed Price (FFP)
• Fixed Price Level-of-Effort (FPLOE)
• Cost Plus Fixed Fee (CPFF)
• Cost Plus Award Fee (CPAF)
• Time and Materials (T&M)
• Delivery/Indefinite Quantity (ID/IQ)
• Ordering Agreement (BOA)
• Order (P.O.)
• Letter Contract
• Letter of Intent
21. Prime Contracting
• Pros
• Prime contractors maintain control of the project.
• Prime contractors retain larger revenue share.
• Prime contractors receive larger exposure for the program.
• Cons
• Prime contractors are responsible for the cost and effort
associated with assembling the proposal document.
• Prime contractors assume all of the risk
22. Subcontracting
• Pros
• In a non-exclusive role, the subcontractor can participate on
many teams, thus increasing the chances of being on the winning
team.
• Less risk for the subcontractor means less liability.
• Cons
• Subcontracting nonexclusively generally requires putting together
several scopes of work, thus increasing the costs and resources
expended in developing the proposal.
• Subcontractors have little or no control of the program.
• Subcontractors usually have less input into the proposal process
(less effort and less cost).
• Subcontracting usually means less project revenue.
23. Quality assurance
• Acceptance Criteria Specifications
• QA/QC Workflow
• Automated Quality Control Checks
• Visual Quality Control Checks
• Sampling
• Process Monitoring and Documentation
25. Assembling Proposals
• Questions
• What you intend to provide for them
• How you intend to do the job
• What the time frame for completion is
• How much it will cost the client
• Roles
• Proposal Manger
• Proposal Coordinator
• Technical staff
• Contracts Administrator
• Cost Estimator
26. Typical Sections of a Proposal
• Executive Summary
• Solution Overview
• Scope of Work
• Schedule
• Qualifications
• Costs
• Exceptions and Comments
• Appendixes
27. Task Definition
• Common Design Tasks
• Common Application Design Tasks
• Common Database Development Tasks
• Scope of Work Development
• Schedule development
• Work Breakdown Structure (WBS)
• Costing
32. Project Phases
• Project Initiation
• Project Planning
• Project Execution
• Project Monitoring and Control
• Scope of Work
• Schedule
• Budget
• Quality
33. Level of Effort
Execution
Planning
Initiation Closeout
Control
Project Project
Start Finish
Time
34. Project Initiation
• WBS Element Review
• Project Manager Selection
• Project Staff Roles
• Provide a clear definition of skills and responsibilities required for
specific project roles.
• Be known as a proactive project manager who appreciates the
development team.
• Hold out for the most qualified staff, even if lesser qualified personnel
are available immediately.
• Identify staff interested in the project domain.
• Recognize the need for training team members who lack specific
competencies, and include staff training in the project plan, if needed
39. Develop the Project Plan
• Project Overview
• Scope of Work
• Assumptions and Deliverables
• External Dependencies and Constraints
• Resource Requirements
• Project Organization and Structure
• Key Contact Information
• Work Flow Process
• Project Schedule
• Communication and Reporting
• Risk Management
40. Example Work Flow Chart
RCTLMA trail Conduct needs Design Develop terrain
Digitize trails
mapping analysis Geodatabase model
Develop Review Finalize project
Client review Yes
methodology methodology documentation
Edit methodology Edit Deliver final
No Yes No
process documentation product
42. Defining the Quality Assurance Plan
• Quality audits and process analysis
• Statistical sampling
• Application testing
• Inspection
• Edit review
Change Control Process
49. Definitions
• Client-mandated implementation methodology
• Internal organizational standards
• Nature of the work
• Complexity and duration of the project
• Waterfall Methodology
• Evolutionary Prototyping
• Staged Delivery
50. Waterfall Methodology
• Requirements, product specifications, and technology environment
are well known
• Quality requirements are more important than cost or schedule
constraints
• Staff is inexperienced
• The project scope is small and short term
• The project is complex, but well understood
51. Evolutionary Prototyping
• Rapidly changing requirements or the application area is not
well understood by developers or the client
• Project needs to show visible progress throughout
• End user driven application
• Schedule and cost constraints are not a primary concern
52. Staged Delivery (Incremental
Implementation)
• Requirements are well defined, but a framework is needed to
accommodate some changes including changes in implementation
priorities.
• The project is complex with a mid- to long-term implementation
timeframe and has different modules with considerable variability
in terms of implementation priority.
• Showing continued progress in the form of production ready
software components is important.
• Project management and technical staff are experienced, especially
at the planning level.
• The project can absorb the overhead that comes with added
planning and software release activities.
58. Project Monitoring and Control
Project Planning
Project Monitoring Project
and Control Execution
Scope Requirements
Quality Analysis
Schedule Design
Cost Development
Risks
Testing
Human Resources Deployment
Customer/ Stakeholder
Management
59. Start
• Scope • Customer/Stakeholder
• Quality Management
• Schedule • Analysis inputs
• Cost • Analysis based on standard
methods and tools
• Risks
• Analysis outputs
• Human Resources
60. Scope
• Original scope of work from the project plan including work
packages (i.e., work breakdown structure [WBS])
• Information on project performance including, for example,
completed tasks, defect statistics, cost and resource utilization,
and status of scheduled activities in the scope of work
• Approved change requests including changes in priorities that
may lead to re-planning
61. Quality
• Quality audits and process analysis
• Statistical sampling
• Software testing
• Inspection
• Review of defect fixes
62. Schedule
• Analysis inputs typically identify which target dates have been met
and the extent to which target dates
• To track schedule performance, project managers can then
generate a number of reports to assess the current status of work
packages
• A planned versus actual schedule comparison can be effectively
illustrated graphically through bar charts.
• Key outputs from the analysis include reports that document the
status of the schedule as determined through performance
measures and recommended corrective actions
• Typical corrective actions may include mechanisms for expediting
work to allow completion within schedule or, at the least, to reduce
delay.
63. Cost
• Analysis inputs such as information on expenditures obtained
from the appropriate business systems.
• Many times, only cost overruns are considered of interest in
project performance reviews because of their negative effect on
project profitability
• Results of the earned value analysis and forecasting effort
• Recommendations on corrective actions, if variances are
excessive
64. Risk Mitigating Strategy
Insufficient resources Explore various channels to secure resources,
available to perform including hiring new staff or involving
the work subcontractors, or consider training staff who
currently lack sufficient skills.
Consider alternative implementation approaches
or rescheduling and reprioritizing work.
Hire top talent.
High turnover on the Investigate reasons for turnover and provide
project team feedback on possible corrective measures to
management.
Improve team cohesion through proactive
communication.
Work to establish a project environment for
success.
Poor team dynamics Involve interactive team management to identify
issues and act as facilitator to resolve team issues.
Implement processes to escalate conflict
resolution to senior management if needed.
65. Friction between the Establish clear lines of communication between the
project team and the project team and the customer.
customer Proactively manage communication.
Develop issue logs and plans to track and resolve issues.
Follow up on action items.
Ensure all project status information is accurate and up-
to-date.
Contractor failure Check references.
Assess abilities prior to hiring.
Provide a scope of work that clearly identifies
responsibilities.
Actively manage the contractor relationship.
Overly optimistic Incorporate adequate time for planning, design, testing,
schedule bug fixing, retesting, changes, and documentation, and
properly account for nonworking time such as weekends,
holidays, and staff vacations.
Solicit feedback from the technical team when
scheduling work.
Properly account for schedule dependencies including
stakeholder dependencies that are not directly
controllable.
66. Poorly defined Develop clear, complete, detailed, cohesive, attainable,
requirements and testable requirements that are agreed to by all
players.
Use prototypes to help nail down requirements.
In "agile"-type environments (fluid, changing
continually), frequent coordination with customers/end
users is necessary.
Scope creep Work closely with customers when developing
requirements.
Use issue logs for customer communication.
Implement change control and configuration control
mechanisms that identify the processes and approvals
needed to implement change.
Be prepared to defend against excessive changes and
additions once development has begun, and be
prepared to explain consequences.
Use incremental development practices.
Inadequate design Insist on approved requirements prior to initiating
design.
Provide specifications on design standards.
Allow sufficient time for design activities.
Conduct design reviews.
67. Poor software Insist on validating requirements and design
quality specifications.
Require walk-throughs and inspections when
appropriate.
Initiate review and testing early on; retest after
fixes or changes.
Plan for adequate time for testing and bug
fixing.
Analyze the causes of errors with the objective
of implementing process improvements.
Use formal tools to track software discrepancies
including their resolution.
Base Explore alternate implementation approaches.
technology/tools Incorporate cost and schedule contingencies
not ready for into the project baseline.
deployment
68. Human Resources
• Staffing assignments and team roles and responsibilities,
project performance reports
• Active participation in key project activities and continued
interaction with the team
• Project Performance Appraisals
• Conflict Management
72. Client Communication
• Provide information in the form of a question, rather than just say
“No”
• Use the team approach
• Avoid bringing in contract officers early
• Do not pass the buck
• Be informed on all relevant communication with the client
Managing Client Expectations
73. Dealing with Project Problems
• Contract Problems
• Insufficient Project Plan
• Lack of Control Over the Product Dev. Process
• Staffing Problems
• Excessive Optimism on Budget and Schedule
• Poor Control of Subcontractors
74. • Contract Problems
• Ambiguous definition of project deliverables
• Incomplete view of a product development approach
• Uncertainty regarding the client's involvement
• Unclear acceptance criteria
75. • Staffing Problems
• Inappropriate staff assignments (staff not matched to a task that best
fits their skills)
• Not enough staff assigned to a project (understaffing)
• Too many staff assigned to a project, making them difficult to manage
(overstaffing)
• Poor communication between team members
• High staff turnover (trained team members leave, and costs associated
with training new staff negatively impact project)
• Poor training of staff
76. • Poor Control of Subcontractors
• Fail to make scheduled deliveries
• Provide poor quality deliverables
• Have communication problems
77. Mitigating Project Problems
• Unrealistic Promises Have Been Made to the Client
• Client Is Disinterested and Detached
• Client Breaks Established Lines of Communication
• Client Will Not Pay
78. Best Practices for Dealing with
Project Problems
• Open Communication
• Evolution of Problems
• Correcting Budget Problems
• Correcting Schedule Problems
• Managing Client Expectations
• Involving Clients in the Development Process
• What to Do When the Client Project Team Changes
79. • Correcting Budget Problems
• Reduce overall staffing levels.
• Reassign existing staff to different tasks.
• Replace existing staff who are not performing up to expectations.
• Improve the development methodology.
• Make more efficient use of computing resources
80. • Involving Clients in the Development Process
• Provide for client reviews of intermediate deliveries.
• Conduct training programs.
• Plan for technology transfer.
• Have clients assist in resolving issues that arise
81. • What to Do When the Client Project Team Changes
• Organize a meeting between both project teams.
• Have a joint review of project requirements, goals, and
deliverables.
• Review management structure, responsibilities, and channels of
communication.
• Identify any new perceived requirements of needs and weigh
them against the project budget and schedule.
82. Project Closure
• Returning Client Materials
• Hard-Copy Archiving
• Reports
• Correspondence
• Data samples
• Plots
• Meeting notes
• Copies of invoices
• Subcontractor's files
• Original correspondence between you and the client
83. Project Acceptance
• Acceptance Criteria
• Examples
• Database Products
• Software Products
• Technology Transfer Plan
• The Acceptance Process
84. • Acceptance examples
• Conformance to database design specifications.
• Meeting a minimum error rate (i.e., 95% of addresses will be
geocoded).
• Applications will have specific functionality.
• Meeting a specific delivery schedule.
• Readability of transfer media.
85. Administrative Closure
• The client has formally accepted all delivered products.
• The client has been invoiced and has paid in full.
• If subcontractors have been utilized for a project, ensure that all
subcontractors have invoiced in full for their services and have been
paid.
• All material transfers have taken place.
• No one else is charging to the project
86. References
• ESRI, 2004, Managing a GIS. Redlands, California, ESRI Press: 133.
• McConnell, Steve, 1998, Software Project Survival Guide. How to
Be Sure Your First Important Project Isn't Your Last. Redmond,
Washington, Microsoft Press: 288.
• McConnell, Steve, 1996, Rapid Development, Taming Wild Software
Schedules. Redmond, Washington, Microsoft Press: 646.
• Project Management Institute, 2004, A Guide to the Project
Management Body of Knowledge, 3rd Edition. Newton Square,
Pennsylvania, Project Management Institute: 388
With permission from
University of Redlands, CA, International Master of Science, 2005
Full text for GIS class available upon request (Appendix list follows)
87. Appendices
• Glossary • Example of Workflow Diagram
• Example Business Case • Example of an Executive
Documentation Summary from a Proposal
• Example Data Analysis and • Example One of Workflow
Inventory Form Diagram
• Example Request for Proposal • Example of Task Definition and
(RFP) WBS Structure
• Example of Proposal Submittal • Example of Blank Work
Information for a Request for Breakdown Structure (WBS)
Proposal (RFP) Spreadsheet
• Example of Technical • Project Plan Template
Specifications for a Request for
Proposal (RFP) • Example of Quality Assurance
• Example of Contract Terms and
(QA) Plan Template
Conditions from an RFP • Example of Test and Acceptance
Plan Template
• Example of Evaluation Criteria
from a Request for Proposal (RFP) • Corrective/Preventive Action
• Example of an Executive Plan
Summary from a Proposal • Project Completion Report