2026-06-16
A stack of papers arrives in your inbox, labelled something like "Master Services Agreement" or "Consulting Engagement Terms," and your instinct — because you are busy, and because the consultant seems trustworthy, and because lawyers are expensive — is to scroll to the signature line and move on. That instinct is almost always wrong, not dramatically wrong, but quietly, expensively wrong in the way that only becomes visible six months later when the project has drifted into territory nobody budgeted for. The clauses that matter in an IT consulting contract are not the ones that look alarming. They are the ones that look boring: the scope definition, the change order language, the IP ownership paragraph, the liability cap buried somewhere near the end. This piece walks through each of them, in plain language, so that the next time a document lands in your inbox you know exactly where to look and what questions to ask before you pick up a pen.
— Susan Dunmore
2026-04-20
Most vendor selection processes go wrong before the first demo is even booked. The non-technical buyer, usually a founder, operations manager, or department head, sends a rough brief to three vendors, watches three polished presentations, and then chooses the one whose salesperson they liked best. That is not a process; it is expensive guesswork dressed in calendar invites. What follows is the approach I have seen work repeatedly for organizations that have real operational needs and no dedicated IT function to lean on, written plainly enough that you can adapt it to a CRM search, a warehouse management system, a fleet-tracking platform, or almost any software or hardware procurement you are facing right now. The goal is to give you enough structure to make a defensible, genuinely informed decision, even if you cannot read a line of code or interpret a system architecture diagram.
— Susan Dunmore
2026-04-07
The decision to bring in a fractional CTO is rarely made with full information, and I say that not as a criticism but as an observation about how technology leadership actually gets procured in practice. A founder discovers the term, reads a few LinkedIn posts, and begins to wonder whether the gap they are feeling — between what the engineering team is doing and what the business needs it to do — is exactly the gap this arrangement is meant to fill. Sometimes it is. Sometimes what they actually need is a single, well-scoped engagement with a clear deliverable, and a fractional relationship would be expensive scaffolding around a problem that does not require it. I want to try to draw that line as honestly as I can, because I have been on both sides of it, and because the distinction matters more than most consultants will tell you.
— Susan Dunmore
2025-04-16
A bakery owner in Kitchener collects customer email addresses at checkout, stores them in a spreadsheet on a shared Google Drive, and sends a monthly newsletter using a free Mailchimp account — and has never once thought about whether any of that is governed by federal privacy law. A physiotherapy clinic in Halifax keeps scanned intake forms in a folder on a receptionist's desktop, password-protected with the clinic name followed by an exclamation mark. A two-person e-commerce shop in Calgary accepts online payments, logs customer addresses, and uses a third-party analytics platform that drops cookies tracking behaviour across the internet — and their privacy policy, if they have one at all, was copied from a competitor's website sometime in 2019. These are not outliers. They are, in my experience reviewing small business operations across Canada, remarkably ordinary situations — and all three of them carry real legal exposure under PIPEDA, the Personal Information Protection and Electronic Documents Act, a federal statute that has been in force since 2001 and that most small business owners have heard of only vaguely, if at all.
— Susan Dunmore
2025-02-15
The most expensive cloud project I ever watched unfold was not the biggest one. It was a forty-person professional services firm that decided, in the space of a single board meeting, to move every system they had — their accounting platform, their document management, their CRM, their shared drives, their telephony — to the cloud over a single long weekend in March. By the Tuesday morning that followed, three of those systems were partially broken, two were not talking to each other, and the firm's senior partner was on the phone to me at seven in the morning asking whether it was possible to just roll everything back. It was not, not cleanly, and the cleanup took six weeks and cost considerably more than a careful, phased migration would have. I think about that Tuesday morning fairly often, because the impulse that drove that firm's decision — the desire to get it done, to stop managing two parallel environments, to just be in the cloud already — is completely understandable. It is also almost always the wrong instinct for a business under a hundred and fifty people, and I want to explain why, in some detail, and then sketch out what the alternative actually looks like in practice.
— Susan Dunmore