Handling IT Pushback in High-Priority Projects
The customer's IT and security teams are expected to push back on Full Disk Encryption and related parts of the proposal.
A High-Priority Project Meets Its Reviewers
Imagine a project marked as high priority. A leadership team has committed to a date, a delivery group has a plan, and the work is moving quickly. Then the proposal reaches the customer's IT and security teams, and their reply is not a quick approval. They ask questions, raise objections, and ask for changes. For a team under schedule pressure, that reply can feel like the project is being slowed down by people who do not understand what is at stake.
This article looks at that moment. The question it answers is simple: when IT and security teams push back on a proposal such as Full Disk Encryption, what exactly are they pushing back on, and why should the delivery team expect that pushback to be well grounded?
What do you think happens?
When IT and security teams push back on an FDE proposal, is the pushback usually well grounded or is it mostly obstruction?
Reveal answer
The pushback is correct most of the time, because the IT and security teams are doing the job they were hired to do.
The source treats an objection as the expected output of a team whose role is to examine risk, not as a sign of hostility or bureaucracy.
Following One Proposal Through Review
Before looking at the four objection areas in detail, it helps to follow a single proposal as it moves from the delivery team to the customer's reviewers. A rollout change is proposed. A reviewer raises an objection in one of the areas the review is likely to examine. The objection is then checked on its specifics, and the delivery team answers it directly. The change either gets revised or is approved. The state of the proposal changes at each step, and the diagram below traces that path.
Notice what the diagram does not show: a shortcut past the middle steps. The source says each objection should be examined on its specifics and answered directly, rather than dismissed because a deadline is close. Skipping the examination and the direct answer does not remove the objection. It only postpones the question to a later and usually more expensive point in the project.
The Four Areas of Likely Objection
The source makes a specific claim about FDE: the customer's IT and security teams will push back on it. It does not stop at the encryption control itself. It names the surrounding parts of the proposal that the review is likely to examine. The teams are expected to object in four areas.
- Data-access requests: questions about who may request data and under what conditions
- Identity scheme: how people are identified within the system
- Integration patterns: how the system talks to other systems
- Deployment topology: where the parts of the system are deployed
Why Pushback Is Part of the Review Job
The source gives a clear judgment on this point: the pushback is correct most of the time. It also explains why. The IT and security teams are doing the job they were hired to do. Taken together, these two statements change how a delivery team should interpret a review.
An objection is therefore not automatically a sign of resistance, bureaucracy, or hostility. In most cases it is the expected output of a team whose role is to examine risk in exactly the areas named above. Reading an objection as part of that job lets the delivery team respond to the content of the concern instead of to its timing.
When an objection arrives, first ask which of the four areas it belongs to. Then examine the specific claim behind it. This turns a frustrating delay into a concrete question the delivery team can answer.
Tracing a Data-Access Objection
From a data-access objection to a reasoned response
A delivery team proposes an FDE rollout change. A reviewer from the customer's security team objects that the proposal does not clearly say who may request data from the system. The deadline is close. How should the delivery team handle this objection?
- 1Identify the objection area
The objection concerns who may request data, which is the data-access requests area of the review.
- 2Do not dismiss it
The close deadline is not a reason to skip the objection. The source says each objection should be examined on its specifics and answered directly.
- 3Examine the specific question
The delivery team looks at exactly what the reviewer is asking about data-access requests, rather than assuming the concern is general resistance.
- 4Answer directly
The delivery team gives a direct, specific answer about data-access requests in the proposal, and the reviewer can check that answer against the concern.
- 5Let the outcome follow
Depending on what the examination shows, the change is either revised to address the concern or approved as it stands.
The objection is resolved on its specifics. The proposal moves forward either in a revised form or with the reviewer's concern answered, and the deadline pressure did not replace the examination.
Mistakes That Make Pushback Worse
Common mistake Treating every objection as obstruction
Why it failsThe source says the pushback is correct most of the time because the IT and security teams are doing the job they were hired to do.
Do this insteadRead each objection as the expected output of a review team and examine what it actually claims.
Common mistake Reviewing only the encryption design
Why it failsThe likely objections also cover data-access requests, the identity scheme, integration patterns, and deployment topology.
Do this insteadCheck the surrounding parts of the proposal against all four areas before the review begins.
Common mistake Dismissing an objection because a deadline is close
Why it failsThe source says each objection should be examined on its specifics and answered directly rather than dismissed because a deadline is close.
Do this insteadKeep the examination and the direct answer in the plan, even when the schedule is tight.
Sorting Objections into Their Areas
A reviewer writes: We cannot tell how the FDE proposal authenticates the people who will use the system. Which of the four objection areas does this belong to, and what should the delivery team do first?
Hints
- Look at the four areas named in the source and find the one about how people are identified.
- Think about the order of the steps in the flowchart: examine the specific claim before giving the direct answer.
Explain in two or three sentences why a delivery team that reviews only the encryption design is likely to miss objections, using the idea of the four areas.
Hints
- The encryption control is the core subject; the four areas are surrounding parts of the proposal.
- Consider which of the four areas would remain unexamined.
Key Takeaways
- The customer's IT and security teams are expected to object to an FDE rollout in four areas: data-access requests, the identity scheme, integration patterns, and deployment topology.
- The pushback is correct most of the time because the IT and security teams are doing the job they were hired to do, so objections should not be read as obstruction.
- Each objection should be examined on its specifics and answered directly, not dismissed because a deadline is close.
- A single objection moves from the proposed change, to an objection in one of the four areas, to a specific examination, to a direct answer, and finally to a revised or approved change.