The document summarizes lessons learned from rebuilding a legacy system that took much longer than originally estimated. The key lessons are to understand how existing users interact with a legacy system before making changes, ensure proper scoping by asking all relevant questions, involve subject matter experts in estimating tasks, have a project plan but recognize that different methods may work better than waterfall or agile for certain projects, and focus on the needs of the project team.

1. kbarinthesnow
kaylabaretta
Project Destruction 101

2. Job: Rebuild of a current system to
make it suck less
1 developer
1 designer
3 months
300 hours
3 developers
1 designer
9 months
997 hours

3. So how did this happen?

4. And what did I learn from it?

5. Legacy Systems

6. Don’t touch a legacy system until
you see how the people that are using it
everyday actually use it.

7. Scope

8. A bad scope is basically like
having no scope at all

9. The questions you don’t ask in setting
scope are the ones that will cost your
company lots of money (probably).

10. Estimating

11. If a SME is needed to do the job,
they should be estimating the job

12. Project Planning

13. Failing to plan is
planning to fail
Said by someone much smarter than me

14. Tasks

15. If a task has more than 10 hours in it,
it’s probably meaningless

16. Check-ins/ Stand-ups

17. If you’re not checking in, things might not
be getting done (or not getting done as fast
as they need to).

18. People/ Resources

19. Fight for the resources you need

20. Project Management Method

21. Waterfall isn’t always the right fit
but agile might not be either.

22. Poorly managed projects aren’t
enjoyable for anyone on your team

23. You get to decide how fun a job will be

24. So make things good for your team

25. The End