Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

EDM101: Implementation Practices - Project Management

1,186 views

Published on

Jonathan Powers, Technical Program Manager for the Laserfiche Professional Services Group shares how to establish a methodology to implement Laserfiche as well as discussing the unique implementation features depending on the size of install.

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

  • Be the first to like this

EDM101: Implementation Practices - Project Management

  1. 1. EDM101: Implementation Practices: Project Management Jonathan Powers Technical Program Manager Professional Services Group - Laserfiche
  2. 2. What’s is this class about? ‣ Establishing a methodology to implement Laserfiche ‣ Each implementation is unique • Large versus small? • Overkill? ‣ Why listen to me?
  3. 3. What is a Laserfiche Implementation? ‣ ‣ ‣ ‣ Laserfiche Server Workflow Quick Fields Integration/customization
  4. 4. Terminology ‣ Client: Group asking for solution to be implemented ‣ Solutions Provider: Group implementing solution
  5. 5. Defining Roles
  6. 6. Defining Roles ‣ ‣ ‣ ‣ ‣ ‣ ‣ Project Owner Project Manager Business matter experts Infrastructure team Development team Implementation team Testing team
  7. 7. Defining Roles ‣ Build a “roles” document • Include description of responsibility • Include contact info • Be upfront about team member’s allocations, schedules, and availability ‣ Discuss communication plan • Tip: The more points of contact, the more potential for issues
  8. 8. Project Stages
  9. 9. Project Stages ‣ Isolate your focus ‣ Formal validation that you’re on track after each stage completes (get signatures) ‣ High-level visibility on all project statuses ‣ Structure for project plan/costing sheet ‣ Waterfall (with aspects of Agile)
  10. 10. Project Stages ‣ Stage 1: Certification • Teach everyone the Laserfiche basics • Explain differences between custom and outof-the-box work • Tip: Everyone wants to skip this stage!
  11. 11. Project Stages ‣ Stage 2: Requirements Gathering • • • • In-person Build requirements document/project plan Both sides sign-off Anything not in the document is a new requirement
  12. 12. Side Note: Discrepancies ‣ Contract requirements/deadlines are based on a minimal amount of information ‣ Requirements gathering info is based on more accurate/detailed information ‣ How to deal with discrepancies? • Political decision, not technical • Come to terms before proceeding
  13. 13. Project Stages ‣ Stage 3: Infrastructure Setup • Lay the foundation • Tip: Knowledge transfer opportunity to client
  14. 14. Project Stages ‣ Stage 4: Development and Solution Demonstrations • Build the solution • Demo every two weeks (borrowed from Agile) • Tip: Demo to actual end-users, not just POs
  15. 15. Project Stages ‣ Stage 5: User/Group Set Up • Solutions provider documents user onboarding process • Client responsible for all on-boarding • Tip: Expect issues!
  16. 16. Project Stages ‣ Stage 6: Solutions Provider Functionality Testing • Goals:  Find the issues before the client finds them  Predict the usability complaints
  17. 17. Project Stages ‣ Stage 7: Client Functionality Testing • Part 1: Test with solution provider’s test plan • Part 2: Test with client’s test plan
  18. 18. Project Stages ‣ Stage 8: Load/Stress Testing • Load: Can the system handle the expected amount of load? • Stress: Let’s find the breaking point! • Tip: Everyone wants to skip this stage!
  19. 19. Project Stages ‣ Stage 9: User Training • In-person training? • User-focused documentation? Videos? • Tip: Solution provider does all training, client learns the training process for future sessions and training material creation
  20. 20. Project Stages ‣ Stage 10: Piloting • Work out minor usability issues
  21. 21. Project Stages ‣ Stage 11: “Go Live” • Set up the production environment • Jump in!
  22. 22. Project Stages ‣ Stage 12: Stabilization, Knowledge Transfer, & Hand Over • Before Stabilization: Real-time monitoring • After Stabilization: Knowledge Transfer and Admin Documentation • Formal handover (in writing)
  23. 23. Controlling Scope
  24. 24. Controlling Scope ‣ Tools: • Original requirements gathering doc • “New requirements” spreadsheet
  25. 25. Controlling Scope ‣ New requirement: How much extra time should be added on to the project plan? • Roll back previous work? • Deeper you get into development/testing, the harder/more expensive each change will be to implement ‣ New requirement: Should there be an extra charge? • Political decision, not technical
  26. 26. Controlling Scope ‣ “This is a NOT a new requirement! It just looks like one!”
  27. 27. Daily Standups
  28. 28. Daily Standups ‣ 15 minutes • Parking lot ‣ Update/show project plan ‣ Update/show group to-do list • Tip: Trello.com ‣ PM’s job to keep attendance high
  29. 29. The Project Plan
  30. 30. The Project Plan ‣ “Everyone has a plan, until you get punched in the face.” –Mike Tyson
  31. 31. The Project Plan ‣ Not a vanity plan ‣ Microsoft Project ‣ Delivery dates • At any time, you should be able to answer:  When is the current “go live” date?  If we add/remove X, when is the new “go live” date? ‣ Auto-calculated ‣ Resource sheet ‣ Working calendar(s)
  32. 32. Managing Expectations
  33. 33. Managing Expectations ‣ Good ‣ Quick ‣ Cheap ‣ Pick two. You can’t have all three.
  34. 34. Managing Expectations ‣ “No alarms, no surprises.” ‣ Always be one-step ahead ‣ Get it in writing, don’t be vague • “JPo e-mails”  ‣ Under promise, over deliver • Conservative estimates • Expect the worse

×