> Challenge the when...for items on your critical path, it’s always useful to challenge the due date. All it takes is asking the simplest question: “Why can’t this be done sooner?” Asking it methodically, reliably and habitually can have a profound impact on the speed of your organization.<p>Sounds like a great organization - the person implementing something, who has the most knowledge of how long it will take to implement, needs to be "challenged" by someone who has no clue about how to implement what they are asking for or how long it will take. What they are describing is a broken organization, or the beginnings of behavior that will break an organization.<p>I mean, it's fine to say we need to prioritize implementing certain elements of business logic, so we'll shrink the project scope so that those elements will be implemented faster. But to advise people to "habitually" "challenge" every schedule given by implementers is pathological behavior. It can work for a few months, but then the people doing the work get burned out and leave.<p>I have seen shops with confident IT managers who are not afraid to say "no" to unreasonable requests and deadlines, with a solid team of programmers and admins who have worked together for a while and get along, who have stayed at the company for a while and who have executed well on many projects together, with clean code bases and solid infrastructure, and who generally work forty hour work weeks, with the occasional marathon before a big release, or if things are breaking.<p>I have also seen shops with browbeaten IT managers, often new to the job, who are overrun by their bosses and business unit managers, with an IT team with a lot of turnover (except maybe 1 or 2 embittered people who have been there longer than the others), where people and departments are engaged in office politics, where projects have vague and ever-changing requirements, unrealistic deadlines, death march coding marathons by overworked coders, which are interrupted by putting out fires due to the code base with massive technical debt and broken infrastructure. These are the kinds of companies where the executive "habitually challenges" deadlines the weak IT manager gives him, who gives in and dumps the new unrealistic deadline on his team. This is the kind of company where a programmer is thrown into an existing project at the last minute, because the programmer who was working on it quit, and at your first meeting a Microsoft Project slide is shown and you're told that you're already three weeks behind schedule on your contribution.<p>Which of these two companies wind up succeeding, and which end up floundering or even failing?<p>(The only caveat I give to my own scenario, is that in companies where IT is not central to the business, they can often survive a broken IT department, when their core non-IT business is doing very well. Their company would work even better if they followed the rational scenario, but their broken IT department is not always fatal to the company when they're doing well in their core non-IT business.)