Hello and welcome back to Principles of Software Engineering! I’m Sophie Clarke, joined as always by Alistair Fraser and Emily Carter. If you tuned in last time, we were talking about why software engineering even needs all this process and planning—dodging disasters like Y2K and all that. This week, we’re digging into what it really takes to manage software projects from day one.Yeah, and honestly, every time I hear "project management," I think of endless spreadsheets and, like, paperwork. But it’s—well, it’s so much more than that, right? It’s literally the thing that keeps a project from just… falling to pieces when there’s more than two developers involved.Aye, exactly. You get bad management—or worse, no plan at all—and you’re bound to hit those dead ends: products delivered late, cost overruns, or nobody knowing what the actual requirements are. It’s not just about ticking boxes. In my experience, the project manager’s the one holding the reins on organizing, staffing, sorting budgets—you name it.Right, and there’s that long list, isn’t there? Okay, so you’ve got organizing—figuring out what roles have to be done, who does what. Staffing—actually assigning people and making sure there’s a plan if someone drops out halfway. Direction, giving folks some actual leadership. Estimating—well, that’s always a bit of a guessing game, but you get better with experience. There’s also innovating, representing your team to management, proposal writing, and the all-important planning. Did I get all the big ones?I mean… you pretty much nailed it! And there’s all this, like, hidden stuff, too—conflict resolution, project scoping, dealing with procurement, quality assurance planning, and all that techy documentation stuff. Basically, if something gets dropped, it’s the project manager’s head on the block.Absolutely. Actually, I had a wee project a few years back—client had a fancy new app in mind. Beautiful idea, but nobody on the client’s side bothered saying who was responsible for the API documentation. We get halfway, suddenly everyone’s finger pointing. “Wasn’t that your job?” “No, I thought so-and-so was on it.” Ended up with gaps, finger wagging, a last-minute scramble to patch things before the deadline. All because nobody defined who did what at the start.That’s such a classic! And it just shows how skipping proper planning and role definition can create this domino effect of chaos. It sure explains those horror stories we talked about last week—when everything’s so murky, it’s pretty much a recipe for disaster.So if planning is the backbone, then scheduling is like the—uh, skeleton? No, that’s a terrible analogy. But you know what I mean—it keeps things upright. I always get confused, though, between milestones and deliverables. Sophie, can you help me out?Of course! So, a milestone is like a progress marker—some recognizable endpoint in a project, say, “requirements finished” or “system tested.” It’s a moment to stop and check you’re still on track. A deliverable, though, is an actual thing you hand over—like, at the end of the design phase you might deliver the design documents. They usually go together, but not always. Sometimes there’s milestones you don’t directly deliver anything for.Exactly. And then you get into scheduling—splitting the work into activities, working out timelines, and figuring dependencies. You know, like, Activity B can’t start till Activity A is finished. In Gantt chart-speak, that’s “finish-to-start.” Or you get things that can run in parallel—“start-to-start.” It’s about mapping the relationships, not just writing a list.Right, and, okay, Gantt charts—my old nemesis. The first time I used one was in uni, for my capstone. My team thought we could just wing it, but once we actually mapped our testing and deployment dependencies on the chart, we realized our bottleneck: testing overlapped with a ton of incomplete tasks. If we hadn’t spotted that, we’d have missed our demo week for sure. Visualizing really saved our bacon.I love how practical Gantt charts feel—like a project to plan a concert, for instance. Each task lines up visually, you can see “Book Musicians” before “Sign Venue Contract,” or how promotion stuff overlaps with ticket sales. The bars show how long each thing takes, and the diamonds, those are your milestones. Deadlines, big events—all staring you in the face. No excuse for missing them, really.Aye, but it’s only as good as the info you put in. I’ve seen folk treat the initial schedule as gospel, then reality happens—scope creeps, tasks slip, dependencies change. That’s when you’re thankful you set proper baselines, so you can see when things drift and adjust in time, not after you’re off the cliff.And I gotta say, the act of just sitting down with your team to build a Gantt chart gets everybody on the same page. Suddenly you’re talking honestly about what depends on what, and what happens if, say, the “Review Contract” slips by a week. It forces those conversations way earlier than they’d happen otherwise.It’s all about communication, isn’t it? If roles and schedules are clear, it’s so much easier to spot risks—which, speaking of, takes us to one of the trickiest parts of project management……which is dealing with risk. Not just the scary thunderstorm-in-the-distance type, but all the little “what ifs”—from developers resigning unexpectedly to the customer suddenly deciding they want a whole new feature set halfway in.Exactly. Risks come in all sorts—project risks, which threaten the timeline or budget; technical risks, making the actual building of software tricky or even impossible; and business risks, where maybe it turns out the product you’re building… nobody wants it anymore, or sales can’t figure out how to actually sell it. I’ve seen every flavor, unfortunately.Yeah, and sometimes it’s just a chain reaction. Like, a developer quits, then the project falls behind, then deadlines slip—ugh. But how do you go from just spotting a risk to actually doing something about it?Well, that’s where risk identification and analysis come in. You can use checklists from previous projects, do interviews, have honest brainstorming sessions, or even draw up those Fish Bone diagrams—where you break down causes under categories like people, process, equipment, and environment. It’s not about finding solutions right away, but about surfacing the root causes so you know what you’re facing.Aye, then you quantify it—figure out two things: “How likely is this risk to happen?” and “If it does, what’ll the impact be?” Multiply probability and impact—that’s your criticality or risk exposure. The nastier and likelier it is, the higher up your to-do list it should be.I absolutely need risk tables in my life for this. You just list your risks, rate the chance and the impact, map out actions for each. Like, if the risk is “end users resist the system,” maybe the solution is giving them training and showing off the benefits before Go Live. Or if the risk is tight deadlines, your plan might be strict adherence to the schedule—and maybe a backup plan if things start slipping.Oh, for sure! I had this project a while back—loads of resistance from end-users. So we flagged it as a high-risk on the project table, with a big price tag if it blew up. Our mitigation was a series of hands-on training sessions, and regular check-ins—to empathize, answer questions, the lot. We watched “probability” drop in our risk table over time as engagement went up, and the eventual rollout was almost painless. That table becomes a living, breathing thing, constantly updated as the project evolves.And it’s not just about mitigation—there’s risk monitoring too. Keeping an eye on early warning signs, regularly reviewing those risks, and having a contingency plan for when things do actually go sideways anyway. Any project without that is just whistling in the wind, if you ask me.I think that’s the biggest lesson, honestly: you can’t dodge every risk, but you can absolutely be ready for the ones that matter most. And documenting all this, keeping everyone looped in—it’s good engineering, not just management.Well put, Emily! That’s all the time we’ve got for today—so next time, we’ll pick up where risk leaves off and talk about keeping your documentation and deliverables on point. Thanks so much for listening, everyone. Alistair, Emily, it’s always a pleasure!Aye, cheers both—see you next time!Yeah, this was super fun. Bye, everyone—catch you in the next episode!

Episodes

Software Project Management Essentials