The pace of business change is not predictable. Technology systems and products must evolve rapidly enough to meet business demands and take advantage of opportunities. The symptoms of technology failures can manifest themselves throughout your organization, but all point to just a few root causes. Ten Mile Square calls the exercise of matching technology problems with their cause — Technology Pathology.
Here is the best way to think about your company’s Technology Pathologies:
- Symptoms are what you see
Technology problems do not stand alone. Chronic problems meeting expectations are caused by underlying technology and business process breakdowns. Treating the symptoms without addressing the fundamental causes makes the symptom go away, for a while. They’ll be back.
- Causes are why you see them
The underlying cause for most technology problems are driven by poor product development lifecycle practices. Most technology practitioners are skilled in a small segment of the product lifecycle. They answer “why” questions with opaque circular arguments relevant to their small world view. Why? Behind the techno-babble, they don’t understand the motivation for applying technology to a business problem.
- Solutions are how you treat the causes
Throwing a best practices blanket across a technology fire smothers everything, good and bad. In order for a technology problem resolution to bring immediate business value it needs to be well targeted. Otherwise, a solution that’s too broad has the unintended consequence of reducing technology productivity.
Does your company suffer from these common pathologies?
- Technology teams are overwhelmed with work
- Product releases are a surprise party
- Small changes take much longer than are reasonable
- Nagging problems never seem to go away
- The technology development pipeline is out of sync with demand
- Product marketing and product capacity are not aligned
- But my problems are unique!
Let’s discuss how to examine address each of these seven pathologies
1. Technology teams are overwhelmed with work
The solution always seems to be: “spend more money,” but that doesn’t solve the problem.
Cause: Lack of Prioritization
There are too many ongoing initiatives within your organization. The inability to focus makes your development team feel overwhelmed with work. For each initiative, there is not consensus on the relative priorities of new features, customer driven customizations and problem resolutions.
Solution: Product Portfolio Review
Define and communicate the relative priorities of the technology initiatives. Answer the “why” questions and tie the initiatives to business goals and milestones. For each initiative, prioritize the new requests, customer-driven changes and problem resolutions. Use a priority scheme that does not allow ties. Recognize that life changes, new opportunities arise, and the priorities need to be revisited regularly.
2. Product releases are a surprise party
They are frequently delivered late, or not at all, and fail to meet expectations.
Cause: Lack of Transparency
Non-technical managers and contributors do not have the ability to validate progress towards completion. Project documents are geared towards internal development teams and do not present regular checkpoints that allow business sponsors to see progress. Big bang development approaches deliver all capabilities at the end of a project with only one opportunity to succeed.
Solution: Product Plans and Milestone-Based Development Plans
Product Plans and Milestone-Based Development Plans address the transparency issue at two different levels — “what” and “how” respectively. The Product Plan answers the “what” question by defining the behaviors of the product from the perspectives of the stakeholders. It addresses the stakeholder definitions, nomenclature and business context as well as the human and system interactions.
The Milestone-Based Development Plan answers the “how” question by laying out the development tasks and resources necessary to implement the behaviors of the product. Very importantly, it breaks the product development down into manageable releases that are no more than 6-8 weeks in length with internal milestones that are no more than 2 weeks apart.
The releases and milestones provide a demonstrable test of success that a non-technical manager or contributor can inspect to determine if the goals have been met. If an adjustment needs to occur due to changing business needs or a clarification of need, it is done at a manageable level. This provides more than one opportunity to get things right.
3. Small changes take much longer than are reasonable
Small changes seem to take as much effort as major changes.
Cause: Inflexible and Inefficient Development Practice
How long can it take to make the smallest change possible? Technology releases have a fixed cost for doing a release and all it entails — build, test, deployment, rollback planning and changes to operational procedures. High fixed release costs, in time and money, may mean that the actual changes pale in relation to the cost of a release.
Solution: Software Delivery Optimization
Software delivery optimization speaks to the basic blocking and tackling of taking source code and turning it into a product that is releasable. The key to taking the pain out of a release process is to break the exercise down into manageable and automatable steps. Once the release process has been automated, software developers can work on their products and the release process behaves predictably.
- Continuous build and unit test
- Creation of a valid system and integration test environment
- Release of a fresh build to the test environment
- Automating white box transactional testing using an inexpensive test bench
- Release to production environment and cutover
4. Nagging problems never seem to go away
Things don’t seem to ever reach a finished state. We go from crisis to crisis. If it’s not a crisis, then it doesn’t get done. Divas get all the love.
Cause: Lack of Issues Management
Those uncomfortable nitpicky issues in your systems and products seem destined to eternal life. How hard could it possibly be to clean them up? Your issues management process addresses issues both big and small. Everyone agrees that the big show stopping issues need to be addressed immediately. But, what about the lower priority fit-and-finish issues?
Solution: Make Issues Management a Routine Exercise
Set an issues management pace that is responsive to the workload of the product team as well as the needs of the stakeholders. If the product development team can respond in a predictable timeframe the stakeholders will become comfortable that they are being taken seriously. The product manager and software development manager can report status from a weekly issues review. Providing transparency into the issues management process through issues management tools allows stakeholders to create and watch the evolution of issues. They allow you to answer the question “What does the technology team do all day?” Answer: more than you know. This transparency will provide the business sponsors with enough comfort that the backlog of cosmetic fixes can be addressed.
Free or cheap issues management systems allow you to:
- Capture the issues
- Triage very rapidly
- Differentiate new features requests and problem reports
- Respond to the issue reporter on triage status
- Allow the stakeholder to check status on their issues
- Set expectations on when the issue will be worked: diagnosis, remediation and release planning
5. The technology development pipeline is out of sync with demand
Technology deliveries do not arrive in time to make a business impact or they do not express an understanding of the underlying need.
Cause: Product Roadmaps Not Aligned with Business Drivers
It’s not enough that your technology organization is making progress against the technology goals and objectives. The products need to be released in time to support the business milestones that are the reasons for the existence of the technology.
Solution: Product Steering Committee
The technology team knows that they must respond to the needs of company management. Company management has a reciprocal responsibility. Business and operating plans need to lay out at least quarterly business goals and success metrics. These provide critical input into the product roadmaps. As the business and operating plans evolve, formally or informally, the business leaders must communicate this to the technology leadership.
6. Product marketing and product capacity are not aligned
The current infrastructure cannot handle the client load.
Cause: Product Roadmaps Not Aligned with Business Drivers
Business plans and investment presentations make explicit claims about market size, market share and customer adoption. Software as a service has become a dominant service delivery approach making it imperative that product offerings scale in anticipation of planned and actual growth. As planning pushes scaling points back or opportunities pull them closer the operating capacity of the systems needs to be aligned.
Solution: Product Scaling Planning
Product scaling plans are the bridge between the client adoption curve and the technology infrastructure capacity needs. Scaling plans lay out the desired transaction ramp based on your market analysis and assumptions. Capacity plans work to model the actual ability to meet transaction loads with current and planned infrastructure. Of course, life never occurs according to plan. If you over build, the operational costs will be too high for your business to support. If you under build, you will be unable to grow your business. The right approach is one that allows you to incrementally add infrastructure to support scaling just in time. It’s harder than you might think to get right.
7. But my problems are unique!
Unique, just like everyone else’s problems. There are no limits to the number of symptoms that can be the outcome of a common technology problem cause. But, the pathologies are consistent. There are many fewer causes and solutions than there are symptoms of failure. Ten Mile Square’s Technology Pathology approach addresses these underlying root causes.