Back to Guidebooks

Project Report Card

The project report card is a practice that's in the service of high visibility and team engagement, and it's something that we're evolving at DevMynd. The concept is to keep track of a number of dimensions on a project each week – the kinds of things that can help us celebrate wins, improve process, and identify risks.

There are four categories: Big Picture, Internal Risks, Client Risks, Practices. Each dimension within these categories gets a score on a three point scale: Red (poor), Yellow (Ok), and Green (good). Each week during our retrospectives, the team updates the report card. More than giving ourselves a grade, it's a tool that prompts introspection and growth, and helps us keep having the right conversations.

Big Picture

These are the high-level items, if all we did was score these things it would tell us a lot about the health of a project.

  • Customer Confidence: If we were the customer, how confident would be be in DevMynd's ability to execute this iteration? Do we still feel good about having selected DevMynd for this work?
  • Team Enjoyment: How much fun are we (DevMynd) having on this project? How much are we learning? How much do we enjoy the client and the work?
  • Product Quality: Do we feel that we are delivering a quality product? Is code quality high? Are we proud of what we're delivering?
  • Delivered Value: This one is a bit more abstract. Delivered value can be in a number of different areas: business value, value to the client as a whole, value to the client's dev team (are we teaching them a bunch), etc. At a high level, are we delivering value at our full potential?
  • Value Received: This is the opposite of the previous one, how much value is this project bringing back to DevMynd? This doesn't necessarily mean how much revenue is it bringing in, though that is a part of it. It could be related to the prestige of the client, how challenging/satisfying the project is, whether we see future work with this customer, etc.

Internal Risks

These are risks to DevMynd, and we like to share these with customers because it keeps everyone honest. If our team or leadership are feeling shaky about a project or a client, we should be figuring out why. This frequent risk assessment helps us to have those discussions.

  • Reputation: As a services firm reputation is everything, is DevMynd's reputation in any danger from either actual issues or poor perception?
  • Legal: What is DevMynd's exposure in the unlikely circumstance that something really goes awry, e.g. data or information breach, serious malfunction causing damage to person or property, etc. We like to track this because it helps us have honest, direct conversations with customers about how we're mitigating these things for ourselves, which in turn mitigates them for the customer.
  • Revenue: While we don't want our customers to really care too much about DevMynd's internal operations, we are a business and need to collect revenue. We like to periodically assess the risk of each project to DevMynd's cash-flow. Is the customer paying on time? Do we know of anything that puts future statements of work in jeopardy?
  • Attrition: On particularly challenging projects we like to ask the question: are folks on the DevMynd team burning out and at risk of attrition?

Client Risks

Just like there are risks to DevMynd, we want to flip the table around and look at the project from a customer's perspective. Building this kind of empathy for the stakeholders helps us to detect and deal with issues early, sometimes before a client even brings them up.

  • Engagement: It is critical to success for the team to maintain a high level of engagement with the client stakeholder. Do we have enough face time? Is the client attending standup? Are we getting enough support for story writing and requirements?
  • Budget: Every project has a budget, from startup to enterprise. We review where we're tracking against a client's budget and evaluate what we can do to stay on track.
  • Timeline: Most projects have some calendar milestones. How are we tracking to those milestones? Are we doing a good job of setting expectations, are we meeting them?
  • Visibility: Does the client have enough visibility into the project, team, and process?
  • Maintainability: Can the client effectively maintain the code base that we're building? Are we adequately transferring knowledge? Do they have the skills?

Practices

Having delivered dozens of projects, we've learned the practices that help us deliver high quality, on-time, and on-budget. This is a simple checklist of some of those things. We like to assess each week if we're doing them, and doing them well.

  • Pair Programming: Are we pairing enough?
  • Code Review: Do we need to do more code review? Should we employ pull-request reviews?
  • Automated Testing: Is the test suite solid? Do we need more functional tests? Is the client-side being covered adequately?
  • Communication: Is communication working smoothly? Too much email? Not enough chat? Are we getting enough face-time with the customer?