EDM101: Implementation Practices - Project Management
•Download as PPTX, PDF•
0 likes•1,442 views
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.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to EDM101: Implementation Practices - Project Management
Similar to EDM101: Implementation Practices - Project Management (20)
More from Laserfiche
More from Laserfiche (20)
Recently uploaded
Recently uploaded (20)
EDM101: Implementation Practices - Project Management
- 1. EDM101: Implementation Practices: Project Management Jonathan Powers Technical Program Manager Professional Services Group - Laserfiche
- 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. What is a Laserfiche Implementation? ‣ ‣ ‣ ‣ Laserfiche Server Workflow Quick Fields Integration/customization
- 4. Terminology ‣ Client: Group asking for solution to be implemented ‣ Solutions Provider: Group implementing solution
- 6. Defining Roles ‣ ‣ ‣ ‣ ‣ ‣ ‣ Project Owner Project Manager Business matter experts Infrastructure team Development team Implementation team Testing team
- 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
- 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. 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. 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. 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. Project Stages ‣ Stage 3: Infrastructure Setup • Lay the foundation • Tip: Knowledge transfer opportunity to client
- 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. Project Stages ‣ Stage 5: User/Group Set Up • Solutions provider documents user onboarding process • Client responsible for all on-boarding • Tip: Expect issues!
- 16. Project Stages ‣ Stage 6: Solutions Provider Functionality Testing • Goals: Find the issues before the client finds them Predict the usability complaints
- 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. 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. 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. Project Stages ‣ Stage 10: Piloting • Work out minor usability issues
- 21. Project Stages ‣ Stage 11: “Go Live” • Set up the production environment • Jump in!
- 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)
- 24. Controlling Scope ‣ Tools: • Original requirements gathering doc • “New requirements” spreadsheet
- 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. Controlling Scope ‣ “This is a NOT a new requirement! It just looks like one!”
- 27. Daily Standups
- 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
- 30. The Project Plan
- 31. The Project Plan ‣ “Everyone has a plan, until you get punched in the face.” –Mike Tyson
- 32. 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)
- 34. Managing Expectations ‣ Good ‣ Quick ‣ Cheap ‣ Pick two. You can’t have all three.
- 35. 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
Editor's Notes
- What do people need to know already to get the most out of this class?Describe who this course is appropriate for or who will benefit from it.