Part of my consulting practice is to perform assessments. Sometimes, those assessments discover misalignments between IT and the business. Misalignments show up as “problem” projects, “inadequate” testing, and other typical problems in IT. It turns out, though, that many IT misalignment problems can be solved by small changes in IT work processes.
With 10 years of assessments under my belt, here are the top five issues I look for when assessing organizations, especially when looking for misalignment between IT and the business strategy:
- Lumping all the business stakeholders into one category: the business.” Yes, the IT group exists to satisfy business needs, but calling all the stakeholders one name doesn't help differentiate what each set of stakeholders requires for a given project or system. The finance people want one thing, the salespeople want something else, and all the other groups have individual wants and needs as well. In my experience, the lack of stakeholder differentiation leads to two problems in requirements: incomplete requirements definition and inadequate ranking of requirements. Although the stakeholders are lumped together, the IT group doesn't know enough of the requirements, nor do they demand that the stakeholders agree on which requirements to implement first, second, third, and so on.
- There is no pictorial description of the system. As software people, we assume that the IT staff are the only ones who would use a picture of the product's architecture. However, when architecture pictures exist, IT can explain the workflow and data movement to each of the stakeholders. The various businesspeople can then understand the effects of their requests on the rest of the system.
- The various business stakeholders can only see work in progress when the product is formally released. IT has several techniques to show stakeholders how the system is shaping up. The more traditional approach is to use a staged delivery lifecycle, with interim (monthly, bi-monthly, quarterly) releases. And, IT can choose to implement an entire feature at a time instead of implementing architectural components at one time (implementing by slice).
- Developers and testers don't have enough domain expertise to adequately create and test the system. Domain expertise comes in two flavors: problem-space and solution-space. People who have problem-space domain expertise understand the problems the system solves. People with solution-space domain expertise understand the internals of the system and how it solves those problems. Without understanding the problems the system solves, or how the system solves those problems, the developers can't create systems that meet the needs of the stakeholders — and the testers can't test those systems.
- Inadequate data gathering and explanation to the various stakeholders. When organizations don't have data about their projects, they use intuition and gut feel to make decisions. But everyone's intuition is not the same. And everyone's risk tolerance is different. Those differences mean that people try to talk about the issues, but they come to widely different conclusions with no data to help them arrive at common ground.
You may not have all of these warning signs of misalignment, but if you have any of them, you're probably not doing enough of a job aligning the IT projects with the needs of the business. Review these alignment issues to make sure you've identified that all your users, shown the system flow, can show small pieces of system completion, and hire developers and testers who can do great work and explain your project state. You may still have problems, but they're less likely to be alignment issues.
© 2008 Johanna Rothman.
Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.