Project-Management

TOGAF is documentation-heavy and linear. Scrum is iterative and lightweight. Running them together means breaking the Architecture Development Method into sprint-sized chunks instead of treating it as a single pass from Phase A to Phase H. Mapping ADM phases to sprints The ADM doesn’t have to run in one direction. You can treat each phase as a backlog item and pull work through in sprints. TOGAF Phase Scrum equivalent Preliminary Sprint 0 — governance, tools, team setup Phase A: Vision Product backlog epics for the EA vision Phases B-D: Business, Data, Application, Technology One domain per sprint Phase E: Opportunities & Solutions Backlog refinement for implementation Phase F: Migration Planning Roadmap prioritisation Phase G: Implementation Delivery sprints Phase H: Change Management Sprint retrospectives Roles The Enterprise Architect maps closest to Product Owner — they prioritise the architecture backlog. The Architecture Board shows up at sprint reviews. The Scrum Master facilitates the process and removes blockers. ...

I spent a chunk of last year reading my way through the soft-skills section of the bookshop. Not because I’d suddenly become interested in personal development — more because I was struggling with a project where the technical bits were fine but everything around it kept falling apart. Miscommunications. Teams that wouldn’t align. Stakeholders who seemed to be operating in a different reality. So I started reading. Not the textbook stuff, but the books people actually recommend when they’re being honest. Here’s what stuck. ...

This is a RACI chart specifically for project initiation documentation — who’s responsible for producing each piece of the paperwork that kicks a project off. It’s based on the chart from Project Management for Dummies (Wiley, 2011), which is one of those books people laugh at but actually contains useful reference material. This particular chart maps out who does what during the initiation phase: the business case, the project brief, the risk register, the stakeholder analysis, and so on. ...

A RACI matrix stops the “I thought you were doing that” conversation before it starts. It’s a grid. Down the left side, you list the tasks or decisions. Across the top, you list the people or roles. Where they cross, you mark what each person’s relationship is to that item: R — Responsible. The person doing the work. A — Accountable. The person who owns the outcome and gets to say it’s done. C — Consulted. The person whose opinion matters before a decision is made. I — Informed. The person who needs to know after the decision is made. Why it matters The most common failure mode on a project isn’t that nobody does the work. It’s that two people think they’re both responsible, or nobody thinks they’re responsible at all. ...

Once you’ve got your stakeholder list — the one from the stakeholder list document, filled in with names, titles, and notes — the next step is to stop looking at it as a flat list and start grouping them. A flat list of twenty names is hard to work with. You can’t send the same email to everyone. You can’t run the same meeting with everyone. You can’t make the same promises to everyone. So you split them up. ...

I picked this up a while back and it’s been sitting in my notes ever since. It’s a risk assessment checklist for software projects — the kind of thing you’d run through before committing to a contract or kicking off a big engagement. The original is a ten-page Word document with checkboxes. I’ve reorganised it here so it’s easier to scan. The categories are roughly in order of how you’d work through them: start with requirements, move through design and implementation, then look at process, people, and external pressures. ...

I needed a simple way to track a scrum project without investing in a tool, so I built a spreadsheet template. It’s not meant to replace anything serious – just something to get the structure down on paper before things get messy. You can grab it here: scrum-tmpl-100212 It’s got three sheets. The first is basic project info – organisation, project name, scrum master, product owner, start date. The second is the product backlog, laid out by sprint with room to track effort against each release. The third is an impediments log, so when something blocks the team you write it down with a category, date, and who raised it instead of letting it get lost in a standup conversation. ...

I put together a simple issue tracker spreadsheet for a project I was working on. Nothing fancy – just something to keep track of bugs, tasks, and sub-tasks without the overhead of setting up a full issue tracking system. The idea was to have something lightweight that anyone on the team could open and update without needing special software. You can grab it here: sample issue tracker spreadsheet It’s got the basics: issue type, status, priority, resolution, assignee, reporter, dates, and an SLA column. The sample data shows what it looks like with a mix of open, verified, and closed issues at different priority levels. ...

You can manage scope, time, cost, and quality much more effectively by basing decisions on working software with actual feedback and metrics, not just task items on a project schedule.

There’s no single right way to develop detailed specifications, just as there’s no single right programming language for every application. Different projects demand different techniques. Requirements managers need a mix of skills to adapt to whatever circumstances they’re working in.