Nova: Welcome back to Aibrary, the podcast where we unpack the books that shape how people work, lead, and build things. I'm Nova.

Nova: : And I'm. So, Nova, what's on the reading list today?

Nova: Today we're diving into a book that has quietly become a cornerstone text in the world of IT project management. It's called Project Management for IT-Related Projects, now in its third edition. And before we go any further, I have to make a small but important correction. A lot of people searching for this book attribute it to Patricia Schmidt, but the book is actually edited by Bob Hughes, with a team of four co-authors: Roger Ireland, Brian West, Norman Smith, and David Shepherd. All of them are BCS examiners or course providers for the BCS Foundation Certificate in IS Project Management.

Nova: : Interesting. So this is basically the official textbook for a professional certification.

Nova: Exactly. It's published by BCS, The Chartered Institute for IT, which is the UK's professional body for computing. Think of it as the British equivalent of the IEEE Computer Society or the ACM. And here's what I find fascinating: this book is only about 162 pages long. That is shockingly concise for a project management textbook. Most PM books are doorstops.

Nova: : One hundred sixty-two pages to cover the entirety of IT project management? That seems... ambitious. Almost suspiciously short.

Nova: That was my reaction too. But here's the thing: it's not trying to be an encyclopedia. It's designed as a practical introduction for IT practitioners who are stepping into project management roles for the first time. The authors explicitly say the goal is to give people a foundation they can build on, not to cover everything. And the reviews are glowing. George Williams, writing for the BCS, called it a project manager's must-have book and gave it a 10 out of 10.

Nova: : Okay, I'm intrigued. Let's dig into what makes this slim volume so effective.

Nova: That's exactly what we're going to do. We'll walk through each of the eight chapters, pull out the most practical insights, and figure out why this book has become essential reading for anyone managing technology projects.

Nova: Chapter one sets the stage by asking a deceptively simple question: what is a project? The book defines it as a temporary undertaking with a defined start and finish, undertaken to create a unique product or service. But here's where it gets specific to IT: the book immediately connects project management to the system development life cycle, or SDLC.

Nova: : The SDLC. That's the classic waterfall model, right? Requirements, design, build, test, deploy.

Nova: That's one version, yes. But the book makes an important distinction early on. It doesn't just present the waterfall model as the default. It walks through the waterfall model, an incremental model, and an iterative model, and then discusses how your choice of development approach fundamentally shapes how you manage the project. If you're doing waterfall, your planning is front-loaded. If you're doing iterative development, your planning is more adaptive.

Nova: : So the book isn't just a PRINCE2 manual dressed up for IT.

Nova: Not at all. In fact, one reviewer on Goodreads noted that it's entirely complementary to PRINCE2, not redundant. PRINCE2 gives you the methodology, the process framework. This book gives you the principles and practical techniques underneath. They work together.

Nova: : What else does chapter one cover that jumped out at you?

Nova: It introduces the concept of the business case, and this is huge. The book insists that every IT project must be justified in business terms before it even begins. It covers net present value calculations and payback period analysis, right there in chapter one. And it also covers implementation strategies: big bang versus phased rollout, parallel running versus cutover. These are decisions that can make or break a project, and the book puts them front and center.

Nova: : So before you write a single line of code or configure a single server, you need to know why you're doing it and how you're going to land it.

Nova: Precisely. And the book ties all of this to a running case study called Canal Dreams, a fictional company that needs an e-booking system enhancement. Throughout all eight chapters, you see the same project from different angles, which is a brilliant pedagogical device.

Nova: Chapter two is all about project planning, and this is where the book really earns its reputation for clarity. It starts with something called a product breakdown structure.

Nova: : Wait, product breakdown structure. Not work breakdown structure?

Nova: Good catch. They're related but different. The product breakdown structure is about what you're delivering: the products, the deliverables, the outputs. A work breakdown structure is about the activities needed to create those products. The book teaches you to start with the products first, then figure out the work. It's a product-centric approach to planning, and it helps prevent scope creep because you're always anchored to concrete deliverables.

Nova: : That makes a lot of sense. Especially in IT, where the temptation is to immediately start thinking about tasks and coding and testing before you've even agreed on what you're building.

Nova: Exactly. Then the book walks you through product flow diagrams, activity-on-arrow and activity-on-node networks, critical path analysis, earliest start and finish dates, latest start and finish dates, float calculation, and resource histograms. And it does all of this in about 20 pages.

Nova: : That is densely packed.

Nova: It is, but the reviewers consistently praise how digestible it is. One reviewer said it makes the underpinning logic of tools like Microsoft Project easy to understand. You stop seeing the Gantt chart as magic and start understanding the network logic underneath it.

Nova: : And the Gantt chart itself?

Nova: Covered, of course. The book shows how to build one, how to read one, and how to use it for resource allocation. But what I love is that it also covers the limitations. A Gantt chart is a communication tool, not a planning tool. The real planning happens in the network diagrams. The Gantt chart is how you present the plan to stakeholders.

Nova: : So the book is teaching people not just what buttons to push in MS Project, but the thinking behind the buttons.

Nova: That is exactly the philosophy of the entire book. It's principle-based, not tool-based. And that's why it ages well even as software tools change.

Nova: Chapters three and four work as a pair. Chapter three covers monitoring and control, and chapter four covers change control and configuration management. Together, they answer the question: once the project is running, how do you know if it's on track, and what do you do when it isn't?

Nova: : The classic project manager's nightmare: the plan is beautiful, and then reality hits.

Nova: And the book is wonderfully practical about this. It introduces the project control life cycle: monitor progress, compare to plan, identify variances, take corrective action. Simple in theory, messy in practice. The book covers earned value management, which is one of those techniques that sounds intimidating but the book explains it clearly with cumulative resource charts and earned value graphs.

Nova: : Earned value. That's where you compare the budgeted cost of work performed against the actual cost, right?

Nova: Yes. It lets you answer the question: are we getting what we're paying for? The book shows how to calculate it and, more importantly, how to interpret it. A project can be under budget but behind schedule, or on schedule but over budget. Earned value helps you see both dimensions simultaneously.

Nova: : And change management? I feel like that's where most IT projects go off the rails. Someone adds one little feature, then another, and suddenly you're building a spaceship.

Nova: You've described scope creep perfectly. Chapter four defines change formally and then lays out a rigorous change management process. It covers change management roles and responsibilities, the change request lifecycle, and crucially, configuration management. Configuration management is about knowing exactly what version of everything you have at any given moment. In IT projects, where you might have dozens of software components, configuration files, and documentation versions, this is not optional.

Nova: : The book treats configuration management as a core discipline, not an afterthought.

Nova: Right. And it's tied directly to change control. You can't assess the impact of a proposed change if you don't know exactly what's in the current baseline. These two disciplines feed each other.

Nova: Chapter five tackles quality, and this is where the IT-specific nature of the book really shines. The book doesn't just talk about quality in the abstract. It covers quality characteristics, quality criteria, the difference between quality control and quality assurance, and then it gets into the nitty-gritty: static testing, dynamic testing, the V-model for testing, and evaluating third-party suppliers.

Nova: : The V-model. That's the one where you map testing phases to corresponding development phases?

Nova: Exactly. Unit testing maps to detailed design, integration testing maps to architectural design, system testing maps to requirements specification, and acceptance testing maps to the business need. The book includes a simplified V-model diagram that makes this relationship crystal clear. And it also covers ISO 9001 and capability maturity models like CMMI, so you get both the practical testing techniques and the organizational quality frameworks.

Nova: : And chapter six is about estimating. I have to say, estimating software projects feels like a dark art. Everyone gets it wrong.

Nova: The book acknowledges this upfront. It says estimating is important precisely because it's so difficult. It covers expert judgment, which is basically asking someone who's done it before. Then it covers parametric approaches, like function point analysis, where you estimate based on measurable attributes of the system. And then it covers estimation by analogy, where you compare to similar past projects.

Nova: : The book also has a really useful table that maps top-down versus bottom-up estimation approaches against those three methods. And it introduces the idea of a checklist approach, which is a structured way of making sure you haven't forgotten anything. The key lesson from the book is that no single method is perfect. You should use multiple methods and triangulate. If expert judgment says six months and function points say nine months, you need to investigate the discrepancy.

Nova: : That's such a practical, honest piece of advice. No magic formula, just rigorous cross-checking.

Nova: And that honesty runs throughout the book. It never pretends that project management is a mechanical, formulaic discipline. It's about applying structured thinking to inherently uncertain situations.

Nova: Chapter seven is all about risk management, and it opens with a risk management framework that you can apply immediately: identify risks, assess them, decide on actions, plan and monitor. The book distinguishes between qualitative and quantitative risk assessment.

Nova: : Qualitative versus quantitative. So gut feel versus hard numbers?

Nova: Sort of. Qualitative assessment uses scales like high, medium, low for probability and impact. Quantitative assessment assigns actual numbers: a 30 percent probability of a 50,000 pound cost impact. The book includes helpful mapping tables that show how to convert between qualitative and quantitative assessments. And it features the probability impact grid, which is that classic two-by-two matrix where you plot risks to prioritize them.

Nova: : The risk register and risk record are also covered. The risk register is the master list of all identified risks, and the risk record is the detailed profile of each individual risk, including its owner, mitigation actions, and current status. The book treats risk management as an ongoing discipline, not a one-time exercise at the start of the project.

Nova: And then chapter eight brings it all home with project organization. This is the people chapter. It covers programs versus projects, stakeholder identification, organizational frameworks, the desirable characteristics of a project manager, the project support office, team structure, matrix management, team building, team dynamics, management styles, and communication methods.

Nova: : That's a lot of ground in one chapter.

Nova: It is, but it's the chapter that reminds you that projects are delivered by people, not processes. You can have the most beautiful Gantt chart and the most rigorous risk register, but if your team isn't functioning and your stakeholders aren't engaged, your project will fail. The book covers Tuckman's team development model: forming, storming, norming, performing. And it discusses different management styles and when each is appropriate.

Nova: : The matrix management section is particularly relevant for IT. Most IT professionals report to a functional manager while working on a project led by a project manager. That dual reporting structure creates all kinds of tension, and the book addresses it head-on.

Nova: It also covers communication methods in detail: when to use written communication, when to use verbal, when to use formal reporting, when to use informal check-ins. For a book that's only 162 pages, the density of practical, actionable advice is remarkable.

Nova: So let's pull this together. Project Management for IT-Related Projects is a compact but surprisingly comprehensive guide edited by Bob Hughes with a team of four co-authors, all BCS examiners and course providers. It's the official textbook for the BCS Foundation Certificate in IS Project Management, but it's also used in university courses and by practitioners who just want to get better at their jobs.

Nova: : The structure is brilliantly clear: eight chapters that walk you from the fundamentals of what a project is, through planning, monitoring, change control, quality, estimation, risk, and finally the human side of project organization. Every chapter has learning outcomes, practical activities, and self-assessment questions. And the Canal Dreams case study runs throughout, giving you a consistent example to hang the concepts on.

Nova: What I think sets this book apart is its honesty. It never pretends project management is easy or formulaic. It acknowledges that estimation is hard, that risks are uncertain, that teams are messy. But it gives you structured, practical approaches for dealing with all of that complexity.

Nova: : And the principle-based approach means it doesn't go out of date when the latest software tool gets replaced. Whether you're using Microsoft Project, Jira, Asana, or sticky notes on a wall, the underlying logic of network diagrams, critical path analysis, earned value management, and risk registers remains the same.

Nova: For anyone stepping into IT project management for the first time, or for experienced practitioners who want a refresher on the fundamentals, this book delivers an enormous amount of value in a very small package. As one reviewer put it, if you're studying for the BCS exam, this is an easy-to-use textbook. If you're not studying for the exam, it's still an excellent practical guide.

Nova: : The key takeaway? Good project management is not about mastering a methodology. It's about understanding principles, applying structured thinking, and never losing sight of the people who actually do the work.

Nova: This is Aibrary. Congratulations on your growth!