Project design and management


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Project design and management

  1. 1. Project Design andManagementAndrew ZolnaiKuwait City & Cambridge
  3. 3. Project Definition - Find a Client - Select a TopicProject Find Work Quality - Develop Initial Project Concepts Assurance Proposal Development Project Implementation Project Performance, Monitoring and Closure
  4. 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
  6. 6. SWOT Analysis Environmental Scan / Initial Analysis External Analysis / / Strengths Weaknesses Opportunities Threats I SWOT Matrix
  7. 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. 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. 9. Opportunities• An unfulfilled customer need• Arrival of new technologies• Loosening of regulations• Removal of international trade barriers
  10. 10. Threats• Shift away from the firms products• Emergence of substitute products• New regulations• Increased trade barriers
  11. 11. SWOT Matrix Strengths WeaknessesOpportunities S-O Strategies W-O Strategies opportunities that are a weaknesses to pursue good fit to the opportunities companies strengthsThreats S-T Strategies W-T Strategies identify ways that the establish a defensive plan firm can use its strengths to prevent the firms to reduce its vulnerability weaknesses from making it highly susceptible to to external threats external threats
  12. 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
  13. 13. Planning• Resource Requirements• Required Level of Effort• Risk Analysis and Contingency Planning
  14. 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. 15. Data Analysis• Data Analysis and Inventory• Conceptual Database Design • Model the Clients View • Model the Clients View • Identify Representations of Entities
  16. 16. Application Development Process• Avoid Classic Mistakes • People-Related Mistakes • Process-Related Mistakes • Technology-Related Mistakes• Develop Fundamentals • Management Fundamentals • Technical Fundamentals
  17. 17. PROPOSALS
  18. 18. Project Origin• RFP• RFB / RFQ• ROM• Spin-off work (sole-source proposals)• Unsolicited proposals• Advertising• Trade shows• Personal relationships/contacts
  19. 19. Selecting Opportunities• General Information• Technical Specifications• Contract Terms and Conditions• Proposal Specifications
  20. 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. 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. 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. 23. Quality assurance• Acceptance Criteria Specifications• QA/QC Workflow• Automated Quality Control Checks• Visual Quality Control Checks• Sampling• Process Monitoring and Documentation
  24. 24. PROPOSALS
  25. 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. 26. Typical Sections of a Proposal• Executive Summary• Solution Overview• Scope of Work• Schedule• Qualifications• Costs• Exceptions and Comments• Appendixes
  27. 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
  29. 29. Project QualityManagement Project Definition Assurance Proposal Development Project Implementation Project Performance, Monitoring, and Closure
  30. 30. Project Implementation• Components • Project Initiation • Project Planning • Project Execution• Performance, Monitoring, and Closure • Controlling the Project • Project Closeout
  31. 31. Project Phases Project Management Phases Initiation Planning Control Execution Closeout
  32. 32. Project Phases• Project Initiation• Project Planning• Project Execution• Project Monitoring and Control • Scope of Work • Schedule • Budget • Quality
  33. 33. Level of Effort Execution Planning Initiation Closeout Control Project Project Start Finish Time
  34. 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
  35. 35. Project Staff Roles• Project Manager • Lead Software Engineer• Senior Management / • Technical Lead Senior Consultant • Database Analyst• Consultants • Quality Assurance Mgr.• Solution Architect • Quality Assurance Lead• Domain Experts / Subject • Quality Assurance Analyst Matter Experts • Release Management Team• Database Architect
  36. 36. Customer Senior Advisor Project Manager , Consultant Quality Assurance , Release Management Technical Lead DatabaseDomain Experts Solution Architect Lead Developer Consultants Architect Software Database Quality Assurance Developers Developers Staff Testers ,
  37. 37. Building the Project Team• Obtain Qualified Project Staff• Schedule Staff Deployment During Project Stages• Maintain Positive Team Dynamics
  38. 38. PROJECT PLAN
  39. 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. 40. Example Work Flow ChartRCTLMA trail Conduct needs Design Develop terrain Digitize trails mapping analysis Geodatabase model Develop Review Finalize project Client review Yesmethodology methodology documentation Edit methodology Edit Deliver final No Yes No process documentation product
  41. 41. Example Project Schedule
  42. 42. Defining the Quality Assurance Plan• Quality audits and process analysis• Statistical sampling• Application testing• Inspection• Edit reviewChange Control Process
  44. 44. Project Execution ProcessACTION ACTOR• Requirements Definition • Executive sponsor• Analysis • Department managers• Design • Technical users• Development • Development• Testing • IT staff• Deployment
  45. 45. Requirements Collection• Inputs • Operational requirements• Task descriptions • Security• Outputs • Maintenance and system• Hardware / software administration platform / architecture • Quality requirements• Data requirements • Documentation• Development environment requirements• User interface
  46. 46. Requirements Documentation• User involvement• Completeness• Managed change control• Describe the "what" not the "how“• Testable requirements
  48. 48. Definitions• Client-mandated implementation methodology• Internal organizational standards• Nature of the work• Complexity and duration of the project• Waterfall Methodology• Evolutionary Prototyping• Staged Delivery
  49. 49. 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
  50. 50. 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
  51. 51. Staged Delivery (IncrementalImplementation)• 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.
  53. 53. How-to• Tracking Project Progress • Dealing with Project Problems including • Contract Amendment Process • Deliverables • Project Closure including • Hours • Final Steps • Budget • Follow-Up• Performance Assessment • Project Acceptance including• Monitoring Staff Performance • Acceptance Criteria• Monitoring Subcontractor • Acceptance Process Performance • Technology Transfers• Managing Client Expectations • Obtaining Payments from• Effective Communication with Client Clients • Project Presentations
  54. 54. Tracking Project Progress• Tracking Technical Performance• Tracking Schedule Performance• Tracking Cost Performance• Performance Assessment Methodologies• How to Obtain Status Information
  55. 55. Example of Project Tasks and TheirStatus
  56. 56. 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
  57. 57. Start• Scope • Customer/Stakeholder• Quality Management• Schedule • Analysis inputs• Cost • Analysis based on standard methods and tools• Risks • Analysis outputs• Human Resources
  58. 58. 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
  59. 59. Quality• Quality audits and process analysis• Statistical sampling• Software testing• Inspection• Review of defect fixes
  60. 60. 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.
  61. 61. 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
  62. 62. Risk Mitigating StrategyInsufficient resources  Explore various channels to secure resources,available to perform including hiring new staff or involvingthe 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 provideproject 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.
  63. 63. Friction between the  Establish clear lines of communication between theproject 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.
  64. 64. 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.
  65. 65. Poor software  Insist on validating requirements and designquality 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  Incorporate cost and schedule contingenciesnot ready for into the project baseline.deployment
  66. 66. 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
  67. 67. Customer/Stakeholder Management• Communication methods• Issue logs
  69. 69. Balance Between ClientExpectations and a FinanciallySuccessful Project
  70. 70. 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 clientManaging Client Expectations
  71. 71. 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
  72. 72. • Contract Problems • Ambiguous definition of project deliverables • Incomplete view of a product development approach • Uncertainty regarding the clients involvement • Unclear acceptance criteria
  73. 73. • 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
  74. 74. • Poor Control of Subcontractors • Fail to make scheduled deliveries • Provide poor quality deliverables • Have communication problems
  75. 75. 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
  76. 76. Best Practices for Dealing withProject 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
  77. 77. • 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
  78. 78. • 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
  79. 79. • 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.
  80. 80. Project Closure• Returning Client Materials• Hard-Copy Archiving • Reports • Correspondence • Data samples • Plots • Meeting notes • Copies of invoices • Subcontractors files • Original correspondence between you and the client
  81. 81. Project Acceptance• Acceptance Criteria • Examples • Database Products • Software Products• Technology Transfer Plan• The Acceptance Process
  82. 82. • 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.
  83. 83. 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
  84. 84. 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 Isnt 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: 388With permission fromUniversity of Redlands, CA, International Master of Science, 2005Full text for GIS class available upon request (Appendix list follows)
  85. 85. 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