
Purchasing software is easy, but managing software effectively is tough. Organizations should consider establishing technology advisory committees (TACs), and marketing technology practitioners need to participate.
These committees provide the strategic oversight needed during the technology procurement process to ensure every new investment aligns with the existing architecture. Such committees can fit into existing procurement processes.
The primary objective of a TAC is to institutionalize governance at scale. By centralizing the evaluation of procurement requests, the committee identifies redundancies — such as disparate teams unknowingly licensing competing project management platforms like Trello and Basecamp — and ensures data interoperability across the stack.
Effective governance prevents tech stack overlaps and ensures departmental platform usage is orchestrated rather than siloed.
Such committees should strive to reduce complexity, cut unnecessary spend, boost product adoption, and increase the revenue (or other critical organization-wide KPIs) derived from the tech stack. By right-sizing or increasing usage, organizations may gain more leverage with vendors.
Plug a technology advisory committee into existing procurement review processes. The point is to improve the return on the organization’s technology investment.
The world’s most powerful SEO platform, purpose-built for Enterprise.
An organization’s closet
A colleague who set up such a committee explained that her teenage daughter likes to buy clothes. However, sometimes she buys something very similar to what she already has in her closet. That doesn’t always make sense and wastes money.
Likewise, organizations should also review what’s in their closets before making a purchase. While having two similar sweaters isn’t a concern, tech bloat can increase the risk of a data breach from forgotten integrations or money spent on underused licenses.
Build the committee
Committee structures should reflect organizational complexity, but certain governance principles remain universal.
Securing a senior executive sponsor is mandatory to give the committee the authority to enforce compliance and defend strategic alignment.
The committee should include technology product leads who support teams throughout the organization. Allow product leads to appoint delegates. That lets them focus their time and effort where they see fit. It also helps more people understand the bigger picture and bring different perspectives. Representatives from procurement and IT security are also essential stakeholders.
A foundational deliverable for the TAC is an enterprise-wide technology catalog. This living document serves as the source of truth for the committee to evaluate new requests against existing capabilities and security standards.
How the committee should operate
Weekly meetings
Governance must stay agile. Committees should maintain a regular cadence — weekly or monthly — determined by the volume of procurement requests, ensuring speed to market isn’t sacrificed for oversight.
Keep meetings succinct (perhaps 30 minutes). Focus on reviewing new submissions and answering committee members’ questions. If there’s nothing new to discuss, cancel the meeting.
Inviting a technology requestor to the meeting may help committee members get the information they need to make a judgment on the request.
Purchase request submission
Technology requestors should have a clear process for submitting requests to the committee. This may involve adding a few fields and a workflow to an existing procurement request form. It might require a new form.
Purchase request appraisal
When sending tasks to committee members, make them easy to complete. Remember, committee members have full-time jobs on top of their committee duties.
For example, when requesting feedback on a new procurement request, strive for simple actions. Give members links in the notification (email, Slack or Teams message, etc.) to approve, reject, or provide an optional freeform response.
A few governance rules
Standardized deadlines should apply to the most common tasks. That clarifies expectations.
It’s also important to set some rules. It’s unlikely every committee member will respond to every new request. Maybe they’re really busy. Perhaps they’re out of the office. They may lack familiarity with the software category at hand. Designate a rule like “three approvals and no objections yield final approval.”
Finally, automation helps. Many workflow platforms can automate procurement request management. This could include automated notifications for submission reviews, triggers to send emails to committee reviewers, and status updates for the requester, procurement, and other involved parties.
TAC processes should run simultaneously with procurement, legal, and IT security evaluations. Many of these processes don’t depend on one another. Since these evaluations typically take weeks, TACs have time to perform their own reviews. That helps prevent the committee from extending the procurement process.
Build organizational support
After establishing the committee, the committee lead should go on a roadshow throughout the organization. They should explain the committee’s purpose and benefits so stakeholders understand the value it brings to them and their teams.
This is a crucial time for the committee’s executive sponsor to reiterate its importance. They should focus on the value the committee offers so that stakeholders view it as a valuable partner rather than another hurdle.
Change management
In most organizations, people will resist a new committee like this. Such pushback is normal. People are under pressure to deliver and receive funding to do so, so they’ll resent impediments. They may, for instance, use a P-Card or find a sympathetic executive to circumvent the committee.
One way to confront such resistance is to demonstrate that the committee only succeeds when stakeholders succeed. That requires understanding each stakeholder’s requirements and pressures. Broad product representation on the committee helps ensure that.
If an organization has a dedicated change management team (focused on persuading humans, not tracking technical actions), a TAC should partner with it.
Martech involvement
Participating in these committees helps martech practitioners build interdepartmental connections. Marketing technology practitioners — regardless of whether they’re on an IT, marketing, or product team — straddle both business and technical realms. They already have broader perspectives than some other stakeholders.
Martech practitioners add value by explaining data flows, stack component dependencies and interactions, translating business requirements into product offerings, and providing other insights. They also provide valuable insight into buy-versus-build decisions and opportunities to enhance existing solutions.
By participating in the committee, they’re better equipped to help stakeholders navigate the procurement process. Marketers will no doubt appreciate the assistance. That alone should help prove the value martech teams bring to the table.
Governance without bureaucracy
Organizations, especially large and complex ones, can easily add bureaucracy. Governance is critical, but institutional overhead can needlessly slow action.
Technology advisory committees offer organizations plenty of value. Clear mission, membership, and procedural guidelines help ensure they deliver more value than they cost.
The post How to build a technology advisory committee that adds value appeared first on MarTech.