Skip to content

Instantly share code, notes, and snippets.

@halyph

halyph/it-department-audit-blueprint-10.md

Forked from raphaelbauer/it-department-tech-due-diligence-checklist.md
Created August 22, 2019 09:18
Show Gist options
  • Save halyph/4fbb02a39175b74d426075e9354279ba to your computer and use it in GitHub Desktop.
Save halyph/4fbb02a39175b74d426075e9354279ba to your computer and use it in GitHub Desktop.
Download ZIP
Raw
it-department-audit-blueprint-10.md

IT Department Audit Blueprint

As IT consultant I work with clients to make cool things happen. My first step in a new project is always to do an audit of the client’s IT capabilities. If the client does not request it I do it anyway - because it is implicitly expected from me to know what is going on.

The following checklist roughly resembles my way of doing the audit. Every client is different, so the checklist is not a one-fits-all solution. But it was always a big help for me to get started. Checklist items on top of a section are more important than items at the bottom.

The golden rule is: If an important checklist item is missing then this might already point to a potential problem. For instance - if a global roadmap is missing then this might mean teams and people have no common goals. But you can fix it easily which will lead to great results.

You can also use this audit if you run an IT department. Make sure you do it once a year and follow up on things that are missing or need improvement.

Let me know what you think!

General organization of the IT department

Culture / Establishing a learning culture

  • Is failure permitted? If you never fail you will never innovate. (The opposite is not necessarily true).
    • There is a strong tension between permitting failure and being slow or too conservative in releasing something new. If teams are NOT allowed to make mistakes they will be very slow in releasing new things. Zuck’s original motto was: "Release fast and break things". But that can go also go wrong if teams only releasy buggy software. Therefore Zuck had to change it to: "Move fast with stability". (http://venturebeat.com/2014/04/30/facebook-has-killed-off-the-move-fast-break-things-mantra/)
    • Tom DeMarco's book "Slack" outlines why risk and uncertainty is needed for successful companies. Managing risk is therefore essential.
  • Are post-mortems done on all levels (teams, management etc)
  • Are pre-mortems for projects being done?
  • Is feedback accepted on all levels? (and also used very very often?)
  • Feedback must be a habit. After talks. After projects. After everything.
  • Is there a "Checklist Culture" to make things reproducible? (eg scrum meetings, depolyments, but also definition of done and similar artifacts). There's even a book about it: Atul Gawande: "The Checklist Manifesto: How to Get Things Right"
  • Is there trust between the teams?
  • Is there a rude tone? People should be nice to each other.

People and teams

  • Are teams delivering things end-to-end? Product should be able to develop cool products with one team and minimal sync with other teams.
  • Is there a healthy team culture. Everyone inside a team speaks. Everyone contributes.
  • Are there employees that are single points of failure? Is mitigation of single points of failure actively pursued?
  • Is there a documented onboarding process for newcomers?
  • Is there a structured hiring process (aligned with career path and salary)?
  • Is there a structured process to promote employees (aka clear career paths)?
  • Is employee churn being benchmarked and acted upon?
  • When people quit - is there a process to get honest (!) feedback to improve things?
  • Is there a structured feedback process once or twice a year for an employee (eg 360 degree feedback).
  • Are there 1:1s between line managers and employees?
  • Is it visible for everyone on which task anyone is working?
  • Do teams have OKRs and or roadmap so they know what to focus on? Do teams know their upcoming milestones?
  • Do teams focus on one topic? (Or do they work on a lot of things at the same time getting distracted without good focus?)
  • Do teams have a documented process (SCRUM eg)?
  • Is simplicity paramount?
  • Is repeatability paramount?
    • Use checklists. Everywhere.
  • Is team maturity taken into account? Are immature teams known and do they get the help they need to successfully deliver products?

Product

  • Is the concept of a "Product Owner" clear
    • There is a difference between someone having authority and driving the product actively and a mere "product task monkey" that delegates stuff to the dev team.
    • From Knitberg (Spotify): https://www.youtube.com/watch?v=502ILHjX9EE
  • Is there a good collaboration between individual product people?
    • Product team meets every week in front of a wall with "initiatives" to exchange what is going on?
  • Product and the development teams strive for simplicity everywhere. Simplicity in product, simplicity in resulting software.
  • How mature is delivery? The terms "agile" and "MVP" must be crystal clear.
    • eg delivering something to the users to get user feedback as fast as possible. Releasing a big bang project is NOT agile and will massively increase the likelhood of failure
  • Is user interaction with features / products being measured and tracked?
    • Make tracking of user interactions an acceptance criteria. This is the basis to make your product decisions. Without that data you are guessing.
    • Don't forget to also track APIs that are used by machines (restful json api, graphql etc). Either monitor them or track them in for - instance - Matomo / Google Analytics.
  • Are unused or not-much-used features being shut down actively?
  • Does product and development teams work and groom new things together? (Grooming session)
    • Product knows what can be sold and what the user wants. Development teams know how to make that happen in the best (and fastest way). Usually there is a sweet spot, where 80% of product requirements can be developed very quickly, but making the rest happen will take a lot of development time. The goal for product and development teams is to find that sweet spot.
  • Is a risk assessment done for product / project? (postmortems / premortems)
    • A failed product / project hurts, but is an important learning opportunity for your teams. Make sure to follow up and get learnings out of it (post-mortems)
  • Are product owners part of the teams (they should be)?
  • Do product owners define acceptance criteria - and are being consulted when developing features?
  • If people quit your product - is a follow up scheduled to find out why?
  • Is there an internship program for devs to put them into the shoes of customer care and into the front line?

Engineering

  • Is simplicity paramount? Simple code. Simple services. Simple IT landscape?
    • Actively reduce the amount of technologies used.
  • If you can - use true continuous development where every feature gets deployed to production (likely behind a feature flag. Uncle Bob Martin calls this true continuous delivery. Others call it trunk based development. There are many names for the same concept. The goal is clear: Less ceremony around "deployments" - More delivery of features to customers.
  • Is a Tech radar in place so that developer have a guidance what to use and what not to use?
  • Do the teams use pull requests and 4 eyes principle?
  • Are there backup and restore drills for services and databases?
  • Are services and systems documented (big board with all services and connections).
    • Document ownership (teams)
    • Document riskiness (and make sure to get rid of risky stuff, put that on the roadmap)
  • Are engineering teams made resilient?
  • Do all services have ‘owners’ - aka teams? (Mark services without ownership as risky to replace them soon).
  • Is the business impact of each service clear? Are service guarantees defined? What happens if a service goes down?
  • Rules of play in place (Eg Security / Authentication / Authorization, coding styles etc, documentation)?
  • Are rules of play enforced? (eg by team lead)?
    • For instance: Are services scanned automatically for security constraints
    • For instance: Is github configured securely and not publicly accessible...
  • Are services easy and fast to deploy?
  • Is a proper test strategy in place (eg how google tests software) testing pyramid?
  • Are there clear OKRs / roadmaps for each team? (Aligned with product). Engineers have to know their priorities!
  • 24/7 in place if needed?
  • Is performance test strategy in place (SLAs, SLOs)?
  • Are teams able to develop features without being blocked by other teams?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment