Project Manager for Magento service

SM / PM Checklist
Client Needs
? On time
? Provide realistic expectations of when a task will be completed
? Provide them an estimate of when it will be ready for their review. This should probably be a range to help manage their expectations. Give them the deadline provided by developers, with a buffer for unexpected problems (e.g. the developers are confident they can have this done by Monday, but because nothing ever goes as planned, it could be as late as Tuesday afternoon)
? Provide them an estimate of how soon after they approve it that it can be on production
? If we are going to miss a deadline
? Let the client know immediately
? Explain the details behind why we are missing the deadline
? Provide a revised timeline
? On budget
? Fixed bid
? All tasks (not projects) will be billed to clients as fixed bid
? If a developer starts a task and finds out that that it is much more difficult than expected, he should provide a revised estimate that goes back to the client immediately for approval before the developer can work on it
? We should come up with an easy way to explain this process to our clients
? Task time should always include time for
? Research
? Time spent before the task is estimated to figure out what needs to be done and provide an estimate. For an 8 hour task this might be 30 minutes
? If the task includes things that we are concerned about we may ask for approval for additional research time to work on small portions of the task to clear up concerns
? Setup
? Development
? Testing
? Code review
? Management. Typically this means adding 20% to a task
? Notes
? Typically non-development time takes about 10-20% of the time
? Unless the client asks, we only need to tell them about the time we need for research and the time for the entire task. We don’t need to tell them how much time is spent on management, code review, etc. For example, if there is a task that we initially think will take 5 hours, we ask for 15 min to dig into the task and provide an estimate. Then we come back with the revised estimate.
? Quick turnaround
? Always focus on minimum viable product. The smallest possible implementation to see a task work
? All tasks should be less than a day so you can merge to master daily. This will keep customers very happy because they will constantly see progress
? If a feature isn’t ready for production yet, use feature toggles to turn it off in production
? Communication to reassure them and manage their expectations
? 30 min response time to questions
? Daily updates on tasks that are in-progress
? Frequent updates on very urgent tasks
? Immediate updates on changes
Developer Needs
? Clear concise tasks
? Clear description. We need to make task creation as efficient as possible so that it doesn’t take a ton of time. Where appropriate screenshots and videos are very helpful and might even provide most of the detail about the description. For example we might have a 1 sentence description of a bug, and then a 2-3 minute video that shows it ---------- need to write up several paragraphs explaining the issue if a quick video will do it.
? Clear acceptance criteria (don’t need to go overboard here, but there should be enough to make it really clear what’s required)
? Small tasks
? Tasks should never be estimated at more than 8 hours (this includes time for QA, management, code review, etc). Preferably development tasks should be broken down so that they are between 1-5 hours
? Priorities
? Need to know exactly what the top priority is at any given time
? Follow-up
? Developers need to have the right amount of follow-up. For a developer that consistently meets deadlines, they need very little follow-up. For a developer that rarely hits deadlines, they need constant follow-up, with the promise that if they start hitting deadlines we’ll leave them alone. If they consistently continue to miss deadlines we will need to let them go
? Know what they are responsible for
? Ensuring they have all requirements needed to complete a task
? Ensuring they have enough information about a task to provide an accurate estimate
? Testing
? Developers are responsible for testing, not the quality assurance team
? Quality assurance is simply there to assure quality, not to test the developers code. They can only test a small percentage of a task that is visible to ---------- velopers must be responsible for their own code.
? Feedback
? Developers need both positive and negative feedback. They need to know when they are doing what we want and when they are failing.

Daily PM Activities - items in bold are very important
1. Communicate with clients
a. First thing in the morning communicate with clients about the latest changes to their tasks, and then throughout the day as required
b. We need you to know enough about tasks to be able to communicate the details about them
c. If the task is urgent, then we may need to update them hourly
d. Keep due dates updated as tasks are completed or delayed
2. Follow up with the team hourly on latest top priority tasks
a. Each team member will likely have a different top priority task so we need to know where each person is on each top priority task
b. Do this in the group chat for their company so everyone knows what everyone is working on.
c. We may be able to reduce this requirement for some people that are on top of their items, and we should make this clear to everyone that if they take care of this themselves they may only need to give us daily updates except for very urgent tasks
3. Meet with team members for a few minutes each day to plan out upcoming tasks
a. Ensure tasks follow the Ticket Workflow
4. Unblock tasks
a. Ensure tickets are unblocked in a timely manner.
b. Ensure that if a ticket was blocked that it describes why it was blocked.
c. Ensure that tasks are truly blocked and aren’t just developers giving up early.
5. Ensure that devs complete the following before signing off each day
a. Summarize completed work on the ticket
b. Add time entries to each task they worked on
c. Update estimate and due date via a comment. If they have to change this, it needs to be mentioned in the group chat and the task needs to be flagged in some way to notify you to notify the client
d. Might be easiest to just ensure that they use the Active Collab timer and put in task details as they switch tasks.
6. Create the high priority list for the next working day
a. Ensure that each task has everything clarified before the day the task starts (preferably this will be ready a week in advance so developers can review, but at the very least is should be prepped the day before). See Ticket Workflow
7. Ensure that we get 1 task per day per client across the line
a. We need to prioritize this against the most important clients, but the goal should be that clients see something important happen every day if something is in their queue
b. Ensure that all tasks are ready for final testing and migration by 10am EST
8. Respond to all clients within 30 minutes
a. We won’t always have the answers within this timeframe, but we need to acknowledge that we’ve heard them, and continue to update them regularly (every 30-60 minutes) until we have an answer.
Weekly PM Activities
1. Reach out to clients to gather details about all upcoming tasks
a. High level tasks
b. Due dates
2. Developer schedules are reviewed (vacation, holidays, overdue tasks, etc)
Ticket Workflow
1. Create task in our PM tool whenever we have a new request from a client
2. Task details
a. Description
i. Should be clear and concise (no unnecessary details)
ii. Should include all screenshots or short (2-3 minute) video if appropriate
iii. Quick discussion with developer to ensure the description is clear and that any additional questions are reviewed and answered
b. Acceptance criteria
c. Time estimate
d. Links to credentials, development servers, assets, etc.
e. Due date - filled out after developer has researched task, client has approved acceptance criteria, and estimate has been approved
f. Subtasks broken down into 1-5 hours each
i. Developer should create these
g. Assigned to developer for review, estimate and work completion
3. Typical workflow
a. Task Preparation - 10% of task time
i. Task details provided by client and initial task created
ii. Discusson with developer to clarify requirements, finalize acceptance criteria, confirm time needed to research task, and give ballpark estimate
iii. Task is reviewed with client, and approval is given for both research time and ballpark estimate
---------- veloper researches task, creates sub-tasks, asks additional questions, and commits to task estimate
v. Final task estimate is approved by client
vi. Task is scheduled for delivery and both developer and client are notified
b. Task Completion - 80% of task time
i. Task is completed within one day
ii. Task is sent for initial code review (quick review to make sure that code meets quality and logic requirements)
iii. Task is sent to QA for final review
iv. Final code review occurs
c. Task Launch - 10% of task time
i. Task is migrated to staging environment for review and approval by client
ii. Task is migrated to production (ideally every task should be migrated to production on the same day that it was started)
iii. Task time is logged for future reference to see how closely the developer adheres to both time estimate and schedule
4. Moving between steps of workflow
a. As tasks complete each stage they should be moved to the correct next step
b. Tasks should be assigned to the appropriate person
c. Tasks should be updated to explain why they are moving

9am-noon EST time
Daily release branches
How to keep from getting blocked on the client review
Planning
1. Tasks should be no more than 8 hours, and preferably 3-5 hours on the high end.
Misc Notes
? Give developers top 3 tasks for the day. Have developers focus on top task only until it is either blocked (need to make sure they don’t just put it here because it’s hard and they don’t want to look any further), or it’s in the hands of the code reviewer. Then they move to task 2, etc.
? Code reviewer then focuses on top priority task first and drops anything else until it’s moved to the next person
? If developer is working on a lower priority task, and a higher priority task comes back from code review, testing, etc. they drop everything and focus on the highest priority task until it’s done again.
? Incentive/Penalties
? Still working out details here, but we need to provide motivation for completing tasks.
? We need to find a way to track this (maybe every task gets an entry in a Google Doc where we can track accomplishments and failures on each task)
? Also need to figure out what to do about tasks where one developer can’t complete it and it has to go to another team.
? Incentives - $2 hourly increase on task if all requirements are met
? Completed on-time
? Passes code review without any major flaws (can have 1-2 minor tweaks, but nothing major like rewriting large chunks of code or logic problems)
? Passes QA first time without any major bugs (1-2 very minor bugs would be ok)
? Penalties - $1 hourly decrease per incident up to $4/hour
? Missed deadline
? Fails code review more than once
? Fails code review for anything other than 1-2 minor tweaks
? Fails QA more than once
? Fails QA for anything other than 1-2 minor bugs
? Hours not updated on task daily
? Task not updated daily with latest comments
? Task moved to blocked when developer could have reasonably continued task