IT business relationship & demand management — $400M publicly traded manufacturer
He Looked at Everything I'd Built and Asked About Project Due Dates.
I spent three years as a translator between four business divisions and a centralized IT organization at a $400 million publicly traded manufacturing company. Regardless of title, my role centered on translating business needs for IT and decoding IT tech speak for the business.
When I arrived, IT had a process. An intake form. Leadership reviewed submissions, created estimates, and approved work. On paper it functioned. In practice it only captured the large, visible projects with budget line items and executive sponsors. Anything under that threshold was invisible. No process, no tracking, no prioritization. Just whoever knew the right person to call.
I became that connector for the business. And then I built the system so it didn't require me anymore.
The relationship started in the bid room
Three months into the role I attended Transportation's annual bid review. The week-long process where the transportation team reviewed shipping lane bids from carriers. I attended to observe. I started taking notes on follow up items from each lane review. I asked a few questions to understand terminology and strategy.
I wasn't positioning myself as an advisor. I was trying to learn the language. How does a bid season actually work? What is the strategy for balancing carriers, volumes and price on a lane and across lanes?
When Transportation decided to run an RFP for a new Transportation Management System later that year, I wrote the first draft. I already understood the business deeply enough to get it 90% complete. The Director and her manager made edits and additions. What would have taken months of requirements gathering took weeks because the relationship had been built in a bid room, not a conference room.
The RACI was the wrong tool.
Sales came with a different dynamic. I built trust through small wins. Spending a few hours of YouTube videos and configuration work to fix a CRM issue which had been challenging the team for months. I architected a knowledge repository inside Microsoft Teams for sales collateral, practice pitches, and customer profiles, then handed the execution to a sales assistant who owned it from there.
When the board requested a new CPQ tool and we ran the RFP, the post go-live support conversation surfaced the real problem. IT preferred producing RACIs to define ownership and accountability. An hour-long RACI review would surface nuance in ownership which never made it into the document.
The RACI was the wrong tool. It described roles. It didn't describe the actual handoffs, the specific scenarios where accountability was ambiguous, or what happened when something fell between the defined boxes.
I wrote an Operational Level Agreement instead. The business read it and immediately viewed it as an improvement. IT was forced to adopt it.
The secret that proved the process.
The IT intake process had a gap. Projects had a path. Everything below project threshold lacked a defined path. Including the 30+ pieces of work I pushed through informally in my first year. No visibility, no sequencing, no way for leadership to see what IT was actually working on or make deliberate decisions on prioritizes.
I built a demand lifecycle process to close that gap. Work could enter at any level and move up or down based on scope and complexity. Projects still went through the intake review but now with full pricing, effort, and time estimates before they were approved, not after. The IT roadmap was maintained as decisions were made, not rebuilt from scratch every quarter.
I led a small proof of concept of the demand management process in Smartsheet. The tool had originally been purchased as an end-around of IT leadership, who frowned on it. By adding single sign on and providing support, I had pulled Smartsheet under IT’s domain. The process decision points worked. When the organization later ran an RFP for a new ITSM, the lead on that project used my Smartsheet proof of concept to develop the requirements document and show the vendor what the company wanted.
He asked about project due dates.
During my year end review my manager looked at everything I'd delivered, the demand process, the OLAs, the TMS and CPQ implementations, the Transportation relationship, the 30+ pieces of informal work I'd kept a list of because no system tracked them. He quickly steered the conversation toward project due dates.
A couple of my project estimates had been off. COVID, bottle necks with key resources and shifting business priorities will do that. He wasn't wrong to raise it. Sitting in that room I understood something I'd been chewing on for years.
Organizations measure what's easy to measure. Schedule. Budget. Scope. There is an entire industry built around those three numbers: PMOs, steering committees, toothless success criteria.
The things which actually matter: did the business get what it needed, did end users adopt the solution, did IT move from a black hole to something the business trusted… well those don't show up in any standard reporting framework. Not at delivery. Not at year end. Not ever.
The Transportation Director who leveraged me to write an RFP knew it. The sales team who finally had a support structure for their application which worked, knew it. The countless end users who had small IT improvements knew it. My manager looked at the same body of work and asked about due dates.
That gap between what organizations measure and what actually matters, is why The Quadrant exists. It forces the conversation a project focused framework does not have room for. Not what did IT deliver. But what does the business actually need, what's working, what isn't, and what are we going to do about it.
That's where I start.