01.20.04
 By
Paul Glen
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.
About the Author:
Paul Glen is the author of "Leading Geeks: How to Manage and Lead
People Who Deliver Technology" (Jossey Bass Pfeiffer, 2002) and Principal
of C2 Consulting. C2 Consulting helps clients build effective technology
organizations. Paul Glen regularly speaks for corporations and national
associations across North America. For more information go to http://www.c2-consulting.com.
He can be reached at info@c2-consulting.com.
Read this newsletter at: http://www.ctoupdate.com/2004/0120.html |
|
| From
the Forum: |
| Microsoft NFR Windows 2003 SBS 5 CAL |
 I
have an unopened copy of Windows 2003 Small Business Server
with a 5 cal liscense. It is marked Not for Resale. Does anyone
know if that means I can't sell it but cn I trade it for like
a good motherboard or something/. ...
|
|
|
