Every January, we’re treated to a plethora of surveys about IT executive priorities for the next year. From year to year, the top one or two items seem to change, but virtually everything below that level stays the same. Beyond the current hot topics, the priorities and problems of IT departments tend to be relatively stable.
One of the perennially favorite issues on these surveys is the alignment between business and technology. It’s one of those things we always talk about but rarely succeed at improving. That’s not because we’re bad people with ill intentions, but because it’s very difficult to actually figure out how to fix this persistent problem.
Most attempts to improve alignment involve changing project processes and adding interviews, documentation and meetings in an attempt to coerce people to agree. Generally, this seems to translate into the practice of holding a project hostage in exchange for complete agreement on every detail of its requirements.
In theory, this doesn’t seem like a bad idea. But in practice, it tends to result in prolonged fights over whether requirements are complete. Plus, clients and users are often reluctant to ever sign off on documents for fear that they’ll be accused of the crime of changing scope whenever they learn something new. Battle lines are drawn between technical teams and business organizations, dividing rather than aligning them.
But poor alignment isn’t the result of deficient processes. It’s the result of failing human relationships. And no matter how exquisitely detailed, processes can’t replace relationships. While a good process can help, a bad process can sabotage relationships and make the problem worse.
To improve alignment, you need to embrace politics rather than process. And you can design politics into your projects from the start.
First, a definition: In this case, politics probably isn’t the kind you’re thinking of. Politics simply means the way groups of people make decisions. Usually, when we talk about office politics, we’re referring to the subset that I call “self-interested politics” — people making decisions about what’s best for themselves rather than for the whole group. Constructive politics takes place when a group makes decisions based on positive criteria rather than selfish ones.
So improving alignment is mostly a matter of designing constructive politics into the project structure. I call it the “advocacy system.” To align business and technology, you should model the political environment of the project within the project team. Each stakeholder affected by a project needs a representative who’ll be an advocate for his interests and needs.
For example, it’s common now to have analysts serve as the project team advocates for the sponsoring executives. They’re concerned with making sure that the project progresses according to the wishes of the people paying the bills and ensuring that the executives have realistic expectations. The needs of various groups of users also need attention. Technical stakeholders need an advocate, too. Deployment specialists, help desk technicians and developers also have explicit needs and concerns.
Once everyone has an appropriate representative, you need to construct the project team to create an appropriate balance of power to model the external environment. You can think about structuring a project like designing a form of representative government. You want to ensure that the majority rules with due consideration of the interests of minorities.
This way, the relationships between the project team and the external stakeholders are designed into the system. Everyone who’s concerned with a project can feel that his interests are being considered — not just in the early phases, but on an ongoing basis. As the project progresses, changes are made and compromises are worked out, such interests receive a fair hearing.
This is how real alignment happens. It can’t be found in strategic plans, grand studies or project documentation. It doesn’t occur as a spasm of good intentions at the beginning of a year or a project. It happens in the little day-to-day decisions about scope, schedule, quality, features and budgets. Alignment happens on the ground every day and is played out in the relationships between stakeholders and project teams.
Click here to sign up for FREE B2B / tech newsletters from Murdok!
Paul Glen is an IT management consultant and the author of the award-
winning book “Leading Geeks: How to Manage and Lead People Who Deliver
Technology” (Jossey-Bass Pfeiffer,2003). He regularly speaks for
corporations and national associations across North America. For more
information go to: http://www.paulglen.com. He can be reached at
info@paulglen.com.
