This document discusses the importance of project reporting and provides examples of different types of reports. It emphasizes sending status reports regularly according to set rules and addressing issues as they arise. The document also highlights the need to manage client expectations and get client buy-in on the project plan and any changes. Examples of status, billing, change and deployment reports are outlined.

1. #MM17DE
§ Status Reports
§ Monthly Snapshots
§ Billing Reports
§ Change Reports
§ Deployment
Project Reporting:The 4 basics*

2. #MM17DE
Brent Peterson
Magento Evangelist
TITLE OFTOPIC
Your Company logo
§ Magento Master. (x2)
§ Magento System Solution Specialist.
§ Forum Moderator.
§ Twitter live streamer.
§ Running Selfie enthusiast.

3. Why do we need all this?
3
Let’s talk about a real client

4. 4
The Client - Kim
§ Strong knowledge of product.
§ Uses the product a lot.
§ Excited to get site launched.
§ Excited to launch other things.
§ May have un-realistic expectations.
§ If left to his own devices he will dictate the
entire plan.
§ (And has nuclear weapons).*

5. The unkempt client
5
§ Client tells you want they want.
§ Client is left on auto-pilot.
§ Asks for many things during project.
§ You do many things (in scope and out).
§ Wait until end of project to tell client about out-
scope items.
§ Client introduces items that cause delay but you
don’t tell them until the end.

6. The involved client
6
§ Client tells you want they want.
§ You re-iterate back what they want
§ Asks for many things during project.
§ You do many things (in scope and out).
§ You report to client IMMEDIATELY when
something is out of scope.
§ You negotiate IMMEDIATELY when a delay
happens.

7. Compress communications
7
§ Choose your reporting rules
§ You should send your status report based on certain rules
§ Measure client happiness
§ Measure and record your clients mood each time you speak
(Ask them ”How is it going?”

8. What could happen?
8

9. Kim’s project burndown
9

10. 10
Kim wants new things

11. 11
Things are goingWRONG

12. Run?
12

13. Or invent time?
13
http://www.ufodigest.com/timetravelsoon.html

14. The Story of the Project
14
§ Projects are filled with real things that happen.
§ You can’t anticipate everything.
§ Plan for the unplannable.
§ Report often and always.
§ Then report some more.
§ And then send a report.
§ The reports will document the final story.
§ Reports should have real data and take about 5-10 minutes to
complete. (For Daily)

15. Every client has these
15
“There are known knowns. These are things we know
that we know. There are known unknowns. That is to
say, there are things that we know we don't know.
But there are also unknown unknowns. There are
things we don't know we don't know.”
-- Donald Rumsfeld

16. 16
Getting the client aligned will align the project

17. Report Examples
17

18. The Status Report
18
§ The report is meant to protect the developer/agency
§ The report should communicate meaningful information to
the client without overwhelming them.
§ The report should take 10 minutes or less to produce.
§ The report should have a way for the client to communicate
back to you.
§ You need to have rules for when the report gets sent and
communicate these rules to the client.

19. The Status Report Data Point Examples
19
§ Features being worked on
§ Timeline
§ Time left
§ Time added
§ Roadblocks
§ Open questions
§ Risks
§ Client health survey
§ Closed issues

20. Monthly Snapshot/ CEO Overview
20
§ The report is meant to give leadership a clear picture of the
current state of the project.
§ The data should be easy to read and digest.
§ Highlight wins and show how issues have been solved.
§ Use lots of pretty graphics.
§ Report should go out monthly.

21. Billing Report
21
§ Each line item should tie back to a ticket or action.
§ Reconcile hours as quickly as possible to reduce disputes
about work completed.
§ Each ticket should align with SOW, CR or another way of
justifying hours.
§ Be ready to be firm but flexible.

22. Change Reports
22
§ Talk about changes as soon as they happen.
§ State the facts and back up your change with the original
statement of work.
§ Don’t allow developers or clients to highjack a ticket.
§ Be ready to negotiate changes, pick your battles.
§ Don’t let CR’s be a blocker to the project.
§ Be clear that changes add time! (Remember we can’t invent
more time …. yet….)

23. BONUS SLIDE – Deployment Report
23
§ Plan and document your deployments.
§ Pick the right delivery mechanism.
§ Communicate all risks with deployment.
§ Try to group as many features into a deployment as possible.
§ If you see risks in your deployments and the client is insisting
on a deployment, have the client sign off on the deployment.
§ Report downtime for deployments vs other factors.
§ Get developers used to deployments.

24. Q/A in the RealWorld
24

25. Thank You
Phone: +1-612-594-7699 Email: brent@wagento.com