Web Project Management


Published on

1 Like
  • Be the first to comment

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

No notes for slide

Web Project Management

  1. 1. WEB PROJECT MANAGEMENTHow to Successfully Structure Web ProjectsBusiness Academy Aarhus - ITDays October 2012Jarne W. Beutnageljwb@eaaa.dkwww.beutnagel.dk/itdays2012/
  2. 2. OVERVIEWThe purpose and structure of this presentation
  3. 3. 1) PROJECT COMPONENTSLogical and controllable division of the project(WHAT, HOW & WHEN)
  4. 4. 2) ROLES & RESPONSIBILITIESDivision of areas of responsibilities(WHO)
  5. 5. WHAT IS PROJECT MANAGEMENT?Achieve alignment, create momentum andensure value deliveryPlanning and structuring resourcesIssue handling
  6. 6. WHAT IS A WEB PROJECT?Projects whose output exist in an onlineenvironment • Web applications • eCommerce / Webshop Solutions • Websites • Etc
  7. 7. 1) A SIMPLIFIEDPROJECT MODELThe components of a Web Project
  8. 8. Planning Production Test (A Typical Model)
  9. 9. Fails to consider other perspectivesIs centered around production, not creating value
  10. 10. Goals Production Validation (A value based model)
  11. 11. Oversimplifies the processDoes not contain control structures
  12. 12. Control Valida-Goals Production tion (A Controlled Project Model)
  13. 13. Project is not groundedThe environment the project exists in has to betaken into consideration
  14. 14. Environment Control Valida-Goals Production tion (A Grounded Project Model)
  15. 15. REALITY:NOT SYNCHRONOUSSeveral phases are often ongoing at the same time
  16. 16. Environment Control Valida-Goals Production tion
  17. 17. Environment Control Valida-Goals Production tion
  18. 18. THE PROJECT ENVIRONMENTUnderstanding the project framing
  19. 19. There are two distinct environments
  20. 20. The INTERNAL EnvironmentThe CLIENT Environment
  21. 21. (even if it is an internal project)
  22. 22. The INTERNAL EnvironmentKnowing the hard limitations of business reality
  23. 23. What to take into consideration (internal perspective) Business Environment • Business Goals • Customer Retention Goals • Placement in the Program Structure
  24. 24. What to take into consideration (internal perspective) Resource Availability • Internal Budget • Time Constraints • Skills • People
  25. 25. What to take into consideration (internal perspective) Motivation • Incentives • Motives • Desired Outcome
  26. 26. What to take into consideration (internal perspective) Attitude / Opinions • Preconceptions • Past Relations with Client • Role of Project Management
  27. 27. What to take into consideration (internal perspective) Support Structures • Infrastructure • Tools • Company Culture • Methodology • Agile Development (e.g. Scrum) • PRINCE2
  28. 28. The CLIENT EnvironmentUnderstanding the Client Needs
  29. 29. What to take into consideration (client perspective) Business Environment • Project Incentives • Program Structure • Career Importance • Stakeholders • Internal / External
  30. 30. What to take into consideration (client perspective) Strategic Goals • Business Goals • User Goals • User Needs
  31. 31. What to take into consideration (client perspective) Constraints • Quality • Project Budget • Maintenance costs • Timeframe • Required involvement • Security
  32. 32. What to take into consideration (client perspective) Pre-Project • Expectations • Knowledge • Experience • Trust • Guaranties • Availability
  33. 33. What to take into consideration (client perspective) Controlling • Transparency • Level of Involvement • Support / Consultation
  34. 34. What to take into consideration (client perspective) Post-Project • Measurability / Metrics • Maintainability • Governance
  35. 35. Environment Control Valida-Goals Production tion
  36. 36. Environment Control Valida-Goals Production tion
  37. 37. GOALSLaying the foundation by strategic alignment anddefining expected value delivery
  38. 38. Purpose: Ensure Measurable Strategic Alignment
  39. 39. PROJECT DOCUMENTS Business Case Reasons for undertaking the project, Goals and Future Life Project Brief Outline of the project structure, Functionality and User Description
  40. 40. PROJECT DOCUMENTS Technical Specs Detailed description of implementation of functionality Test Plan Quality Criteria that have to be approved for final signoff
  41. 41. Business Case• Description of Business Goals• Measurable Metrics• Post-Project Existence
  42. 42. Project Brief• Project Resources• Project Team & Responsibilities• Project Structure • Timeline, Milestones, Deadline• Scope and Functionality• User Description • Use Cases • User Actions
  43. 43. Technical Specs• Requirements• Dependencies• Integrations• Functionality Implementation
  44. 44. Test Plan• Quality Criteria• Types of tests• Approval Plan• Timeline
  45. 45. Environment Control Valida-Goals Production tion
  46. 46. Environment Control Valida-Goals Production tion
  47. 47. CONTROL STRUCTURESControlling the processes and activities
  48. 48. Purpose: Enable steering of the project and ensure client involvement
  49. 49. PROJECT TOOLS Status Meetings Reoccurring client meetings to discuss the status and handle issues Project Tracker Central document keeping track of progress and logging hours
  50. 50. PROJECT TOOLS Issue Log List of issues that arise, their status and plan of action Document Storage A space where project, design and production documents are shared with the team and the client
  51. 51. Environment Control Valida-Goals Production tion
  52. 52. Environment Control Valida-Goals Production tion
  53. 53. PRODUCTIONThe processes and activities that generates theproject output
  54. 54. Purpose: To structure the buildprocess to ensure that the right value is created
  55. 55. PROJECT TOOLS Design Plan This plan outlines the design phases and dictates which processes will be used and the number of iterations sent for approval Prototyping Plan This plan outline what is included in the prototyping process
  56. 56. PROJECT TOOLS Phases Plan The production must be broken down to manageable phases and their structure laid out Development Methodology This defines the development process and framework. For instance, Agile development
  57. 57. Environment Control Valida-Goals Production tion
  58. 58. Environment Control Valida-Goals Production tion
  59. 59. VALIDATIONFinalizing the project by ensuring that goal weremet
  60. 60. Purpose: Confirm that business goals were met and ensure successful project signoff
  61. 61. PROJECT TOOLS Client Acceptance Test The client approves that all use cases and user activities have been satisfyingly implemented Post-Project Deliveries A plan of how the project is to be handed over, including documentation
  62. 62. PROJECT TOOLS Live Plan An overview over the requirements for putting the project live and a detailed timeframe for it Bug Period A timeframe for which bugs that are reported after going live will be included in the project scope
  63. 63. PROJECT TOOLS Signoff A meeting where the client official confirms that all goals and criteria have been satisfyingly met Celebration A gathering where the successful delivery of the project is celebrated and internally showcased
  64. 64. 2) ROLES &RESONSIBILITIESThe division of the project team
  65. 65. ORGANIZATIONAL LEVELS The different team members function at different levels, each with their own specific purpose
  66. 66. ProductionOperational Tactical Strategic Business
  67. 67. WHO WHAT Designers CodeProduction Developers Design IA Architects Testing Team Leads DeliveriesOperational External PMs Tech Solutions Planning Tactical Project Manager Controlling Goals Client Stakeholders Strategies Strategic Consultants Specs External Experts Success Metrics Project Owner Program Managers Project Initiation Business Operational Managers Budget Approval Sales People Account Managers
  68. 68. PROJECT TOOLS Issue Handling Plan A plan for how to escalate issues, when to flag a deviation and who is the final authority Communication Plan An overview over who is supposed to get which information and when
  69. 69. RESPONSIBILITIES LEVELS In the project plan it should be specified which responsibilities each team member has Escalation tree: who reports to who? There has to be a person who is not part of the project team that can be the client authority
  70. 70. TEAM SUPPORT It is imperative that each team member understands their own role and that of the other team members There has to be support for the project structure, both internally and externally Responsibility areas has to be respected!
  71. 71. CONCLUSION
  72. 72. SUCCESSFUL PROJECTSRequires understanding of all the componentsin the projectEnsuring that the right value is created,delivered and measuredCareful application of roles andresponsibilities
  73. 73. Questions?
  74. 74. Thank youSlides are available at beutnagel.dk/itdays2012/