Most companies, when embarking on a major software project, have a fairly good idea what they need to accomplish from a high level. In many cases, though, the business does not know the details surrounding the software project well enough to make it truly a success using meaningful measurements. If you make software for a living, eliciting these details is a normal and expected part of your software development process. But there is one problem associated with software projects that too often gets neglected, but fixing it is a vital part of delivering your software product successfully. I call it organizational debt. To explain what it is and why we should care, I will describe it by drawing parallels to the better-understood problem of technical debt.
What is technical debt?
Technical debt is the term for issues embedded within the code of the software that make it harder to maintain. These issues may not immediately be apparent to a user, but instead are visible to the development team. Examples of technical debt are:
- Different developers working on the project each had their own coding style, making it difficult for someone new to make sense of the whole product.
- The development team put in a complex bit of code that seemed like a good idea at the time, but in retrospect turned out to be a bad idea because it didn't address the root issue. Now no one understands what it is for and therefore everyone just hopes it doesn't break.
- Because of a particular time crunch, the team makes a conscious decision to ignore best practices in order to get a product out more quickly (with the intention of fixing issues later).
Regardless of the cause behind the creation of technical debt, the result is the same – software that is difficult to update without risking breakage in other parts of the system.
How does that compare to organizational debt?
The parallel to technical debt on a company-wide level would be "organizational debt." If technical debt is issues embedded within software that hamper its maintenance, organizational debt would be issues in the day-to-day running of the company that prevent it from operating smoothly. Examples of such debt might be:
- Different departments have their own tools and methodologies to address the same problems, making it difficult for executives to see similarities in order to address company-wide issues.
- Managers create processes or implement software solutions that seemed like a good idea at the time, but didn't address the root cause of the issue and end up creating more problems in the long run.
- Because of a particular time crunch, the team decides to complete a task in a less-than-ideal manner "this time". But that manner is repeated in subsequent tries because no one remembers that the first time was intended to be a one-off situation.
It is important to note that organizational debt doesn't prevent the company from getting work done. Instead, organizational debt prevents a company from getting work done efficiently and effectively.
How does that impede the progress of a software project?
Companies that have a low amount of organizational debt do so because they have a culture that eliminates it on a regular basis. Conversely, companies that have a high amount of organizational debt do so because their culture has trouble distinguishing between value-adding activities and mere busywork. As a result, when they go to build or implement new software, they not only try to implement all of the processes that existed previously, they try to implement all of those processes at once. After all, if they were there before, aren't they vital to the future success of the company?
What can software teams do about organizational debt?
Unfortunately for many development teams, the answer to this question is typically "if that's what the business wants, that's what the business gets." Such thinking leads companies to turn a tangled mess in an old system into a tangled mess in the new one. But smart technology leaders will use the new software implementation as an excuse to create something better. How is that done?
- Start by reading up on various change management techniques. John Kotter's approach is a good one, but there are others out there. Remember, you're never going to get the technology right if the business isn't ready for it.
- Always look beyond requests to understand the underlying business value. Business leaders used to creating quick fixes will continue to think in terms of quick fixes for some time. Getting at the underlying business value will help you and the business leader determine what the right solution is.
- Look for opportunities for consistency. Almost all organizational debt I've witnessed arose because of small-scale solutions to small-scale problems, so encouraging the business leaders to look at the big picture should help.
- Keep in mind what the big picture is, but focus on small changes. Without the ideal final solution in mind, it will be difficult to keep the project on track. But by delivering changes in small increments, you'll decrease the anxiety levels of the people in the organization who are most resistant to change.
Creating software for companies with high amounts of organizational debt is frustrating because nearly everything is more difficult than a company with relatively little debt. But patience and consistency (usually) win in the end.
No comments:
Post a Comment