The following weirdness often happens when we encounter complex business problems.
- The users hate something and want new software. They justify a project to spend $100K replacing something that appears broken.
- The Business Analyst notes a control issue that is really a conflict between software functionality and business rewards.
- The resulting conversation leads to organizational changes.
- The software development project schedule must be changed to accommodate the change.
- This cycle of business change and software change repeats a few times. We are still "analyzing" and haven't produced much.
- The project changes are declared "out of control" and the project is cancelled.
Some good things happened, but the final result -- somehow -- appears bad. One result of the business analysis could have been a rewrite of the application to put in the "20-minute solution"; a simple application which correctly captured the information, supported the decisions and the actions.
The weirdness is, of course, compounded by the famous "schedule compression" technique. This is where IT spins up analysts, architects, designers and programmers all at once. When the analysts throw firecrackers into the hen-house, what is everyone else supposed do to while waiting for the users to settle down again?
Is All Change Disruptive?
Yes. Otherwise, it isn't real change, just incremental adjustment. In some cases, an adjustment is all we need. If so, we don't need a lot of business analysis and software development. If we're making incremental process improvements, then the analysis won't ask disruptive questions.
When analysts uncover discrepancies between "requirements" and the behavior that is rewarded in the user organization, then there are three consequences:
- Change will be disruptive: either behavior or requirements must change.
- The requested software can only be part of the change: behavior is the other part.
- The reward system will have to change, and the software has to fit into that revised reward system.
If the key stakeholders don't express this as a change to the organization, then it's just disruption, and no one likes that. Projects will be cancelled.
User-Initiated Change
One comment points at my lack of clarity here. "Change implies questioning ones assumptions. Even if we can get users to do that, we still have to actually get them to do the hard work of making changes." This quote reveals that the topic (user-initiated change) wasn't clearly articulated.
Change can -- eventually -- result in an IT project being cancelled. Good things happened, but the project only catalyzed the change, and wasn't really part of it. Since this is user-initiated change, the comment doesn't apply. The user's did change their assumptions, and took on the hard work of making a change.
The project was cancelled and IT was blamed -- blamed! -- for a failed project. What was the real failure? Failure to change and improve? No. It was a failure to engage in a technology hobby.
Avoiding change can either lead to the cancellation of a project, or -- worse -- grumpiness with the result. The comment ("even if we can get users to do that") appears to stem from IT is forcing change on users, a situation that makes no sense at all. If we're in the situation where users won't question their assumptions, then we have to ask progressively more disruptive questions until they elect to change.
Tangent: Refusing to Change
I don't really want to talk about flat refusal to change. I mention it here only because this tangent may be the meaning behind the comment. If so, the comment is pretty far off topic.
The topic can be summarized as follows:
- Sometimes user-initiated change leads to project cancellation
- Project cancellation is an IT failure, irrespective of the benefits or the origin of the change.
Refusal to change just doesn't match the topic very well at all. The topic is about IT being a catalyst for change, but not participating in the change by building software.
Here's the situation: during analysis we find contradictions -- requirements don't match behavior -- and the contradictions can't be worked resolved. We're in a tight spot. The users demand change in the form of new software, and refuse to change their behaviors, then what is IT to do? The project is going to get cancelled or denigrated as a waste of money. Which makes more business sense?