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.

Some people believe the best way to estimate a project is to produce detailed requirements and design documents for every feature before writing a line of code. It sounds professional. It sounds thorough. In practice, it usually turns out to be wrong. Requirements change. Priorities shift. The detailed estimate you spent weeks producing becomes irrelevant halfway through the project. That effort becomes wasted inventory – time and resources that could have been spent building something useful instead. ...

In many projects, in order to provide a reasonable probability of success, it will be necessary to reduce the scope by as much as a factor of two. I’ve learned this the hard way. Every project starts with an ambitious list of features and an optimistic timeline. Reality intervenes quickly – resources are tighter than expected, technical problems emerge, and deadlines don’t move. Cutting scope feels like failure. It’s the difference between shipping something that works and shipping nothing at all.

Scrum breaks a product into small pieces (backlog items) and works on them in short iterations (sprints). Here’s how it works in practice: 1. Prepare the product backlog. List the features and requirements. Involve stakeholders to prioritise. The product owner is responsible for the vision and goals. 2. Estimate the backlog. As a team, give a rough estimate for each item. Planning poker or t-shirt sizes work well here. 3. Plan the sprint. A sprint is a fixed period – usually one or two weeks. In the sprint planning meeting, decide the duration, goal, which backlog items to tackle, the tasks for each item, and the hours per task. The result is the sprint backlog. ...

Every programmer knows the urge: scrap everything and rewrite it from scratch. It’s not that the existing code is bad. It’s that it’s hard to understand. Reading code is harder than writing it – you wrote the new code in your head, but the old code belongs to someone else (or to past you, who might as well be someone else). This is why every developer on your team has their own favourite way of splitting strings into arrays. Writing a new function is simpler and more enjoyable than learning how the existing one works. ...