Internal Politics, Budgets, Fear/PrideBy Bruce F. Webster | Posted 2008-08-14 Email Print
Re-Thinking HR: What Every CIO Needs to Know About Tomorrow's Workforce
Baseline columnist Bruce F. Webster analyzes some of the key barriers for project consultants in getting problematic IT systems and IT management on the right track. Included in this perspective is a breakdown of fear, pride, internal politics, and budgets.
Internal politics. Large internal IT systems are seldom the purview of a single group within an organization. Instead, they usually involve several different groups, each of which may or may not be all that happy about having to work with some of the others, but are forced to do so for various budgetary, departmental, or business alignment reasons. In many cases, the development effort itself – analysis, architecture, development, quality assurance – is split across these groups with resulting consequences. As Conway’s Law predicts, you often end up with a system with a truly Byzantine architecture, which may even be the reason the project is in trouble in the first place. The recommended solution is sometimes unpalatable to one or more of the groups involved – due to a loss of control, a loss of functionality, or a change in approach – and so they object to the solution.
Budget. This may seem counterintuitive, but management often finds it easier and safer to have a project drag on year after year, ultimately costing large sums of money, than to spend a relatively small (but still painful) portion of that amount up front and fix the problems now. This is not to say that throwing vast sums of money at an IT project will necessarily fix it. One major internal IT re-engineering project that I reviewed (as an expert witness, not as a consultant) was spending for a period of time $750,000 a day on consultants in a vain attempt to circumvent Brooks’ Law. But often a key purchase of hardware, software, and/or services will help solve the problem – and that purchase is rejected as being “too expensive”, though in the end it turns out to have been far less expensive than the project’s continual delay or problems.
Fear/pride. Fear and pride can be closely related, particularly when the issue is admitting you made a mistake. This is particularly true if a key manager, architect, team leader, or developer has championed or defended a given approach that turns out not to have worked. We don’t tend to reward major mistakes within corporations – except, perhaps, at the CEO level – and so when a proposed solution is in conflict with the defended approach, or worse yet shows it to have been a major mistake in the first place, those with a vested interest in that original approach will often fight against the solution. Even if the original champion(s) acknowledge privately that the proposed solution makes sense, they may be afraid to admit it publicly for fear of losing status, influence, or even their employment.
Note that these barriers aren’t unique to situations when outside consultants are brought into a troubled project or system. IT project managers and engineers are often quite aware of the necessary solutions, but can’t get them accepted for exactly these same reasons. Next week, I’ll talk about what you can do – as an engineer, manager, or consultant – to help the right solutions be implemented.
[© 2008 by Bruce F. Webster]