Information technology people and business people speak different languages. The chief information officer or head of IT speaks in tech jargon, while the chief executive officer and chief financial officer speak the language of market share and return on investment and the heads of marketing and sales beat the drum for enhancing customer experience. To the extent that this disconnect occurs, it is more than a matter of the sides using different words.
2 reasons IT project requirements constantly shift
- Software is a code that works by translating human concepts into the binary language of zeros and ones. Requirements are stated in high-level human language. Sometimes, our groupings of such terms cannot be translated down to workable sets of zeros and ones.
- The state of the art in software and microelectronics keeps changing. Both are relatively young sciences, making it still harder to have requirements and objectives set in stone. A cool feature that would give you a competitive edge today might be obsolete tomorrow, which means you need to aim higher.
Language Gaps Are Thinking Gaps
We know of one company that scheduled a top-level project review meeting. The CIO showed up believing he was superbly well prepared. He had a status report nearly 30 pages long detailing where his IT team stood on each and every task related to development of the software.
The question was not whether the CFO understood these details; the question was whether he cared about the report at all. The CFO was visibly tuned out and turned off. His concern was the money sunk into a project already missing milestones for deliverables. He wanted to know when and how he could expect the whole thing to pay off ... and who could be found to replace the current CIO in order to get the result.
What could have been done better? Many things, but we’ll point out two, one for each side of the gap.
What Could the IT Side have done Better?
Of course, the CIO knew the project was falling behind. It appears that he took the steps that — to his mind, and in his view of the world — added up to the best possible solution: Namely, getting a precise handle on the status of all the technical issues. Perhaps he expected his report to be an ironclad defense from that standpoint. It would demonstrate how firmly he was in command of the foundering ship. But given what the CFO (and probably others) cared about, perhaps a better approach would’ve been to think in terms of collaboration rather than defense.
He could have thought, and said, something along these lines: “Hey, I know we’re behind the curve on this project. My team is trying to get on top of the technical problems, and I can show you the details if you want. But I think the main thing we need to do is put our heads together and figure out the best way forward. Can you give me some guidance? If I explain where we’re stuck, and if each of you explain your issues, can we work out a way to support each other and get to where the company needs to be?”
What Could the Business Side have done Better?
Some companies churn through CIOs the way a struggling football team churns through head coaches and quarterbacks. They bring in a new person, give that person just enough time to fail, and then look for someone else to be the savior. This is a telltale symptom of a lack of trust. More fundamentally, though, it suggests that shuffling personnel is not the solution to chronic underperformance on IT projects. Business executives are best advised to look at their entire approaches to planning and monitoring these projects.
To begin with, the top people on the business side need a working grasp of what a digitization project consists of. This does not mean they must be able to write or understand code as well as hard-core techies do. They should, however, be able to see the IT tech staff (and/or a team of consultants) as more than a black box into which they can put requirements and expect solutions to come out the other end.
In fact, speaking of requirements, a good place to start building bridges is by understanding how a software-intensive project is different from other projects that a company might undertake.
Why Software Is Not Like Other Things
Every IT project begins with a set of requirements. In many cases, they are written out formally. In organizations that adopt an agile development process, they may be implicit in user stories describing how someone would use the product. Either way, there are initial requirements that amount to firm expectations. The company wants a new platform or application that will do this, this and this for the users. Marketing wants to bring out a new product with features x, y and z. That sort of statement or intention is always present at the start.
But almost inevitably, once the project gets underway, it turns out that certain requirements need to change. Often, this greatly annoys the business heads, who are used to setting objectives and managing to those objectives, not seeing them shift beneath their feet. Changing requirements also lead to delays and undermine the credibility of the IT people, who are seen as incapable of following through on a simple plan.
it requirements are at the mercy of code
To begin with, software is literally a code: A model of reality, which works by translating human concepts into the binary language of zeros and ones. (Those are the only “words” that the tiny transistors in chips can understand. To put it simply, each one switches the current on or off at particular times, depending on whether it sees a zero or a one signal.)
The fact that there can be billions of transistors in a single CPU chip — and that by doing their on-and-off dances together with other circuit elements, they can give you directions to the nearest Indian restaurant or play chess — is truly mind-boggling. Most mortals should not try to ponder how such things are possible.
What’s important is to recognize that in this seemingly magical realm, some things may not be possible. Requirements are stated in high-level human language, which includes general concepts we all understand: We want to calculate the average of some numbers or find the shortest route through traffic, or display colors in hues from violet to red.
Sometimes, our groupings of such terms cannot be translated down to workable sets of zeros and ones. Or it turns out they can’t be rendered that way without throwing off other parts of the code. So this is one factor that can cause a need to change requirements.
Software is still a young science
Consider, too, that any new software is meant for uses new to the company. If it’s to be offered to customers in a new market for entry into the market, there may well be unknowns in that market that only come to light gradually. Meanwhile, the state of the art in software and microelectronics keeps changing. Both are relatively young sciences, making it still harder to have requirements and objectives set in stone. A cool feature that would give you a competitive edge today might be obsolete tomorrow, or it might be standard stuff that everybody has, which means you need to aim higher.
These strange qualities tend to aggravate divisions that already exist in a company. Nonspecialists grow suspicious of IT while failing to appreciate its unique demands. The IT people feel pressured and may also feel as if they’re confined to an enclave, with little power to influence the overall strategic direction of the company. And yet both sides need each other. Every business today is an IT business. A company’s only choices are to get the IT aspect and the business aspects working together, or to fall progressively further behind.
