Tech Lead / Product Owner
I've served as a technical lead and product owner for much of my career, even without having engaged in formal Scrum processes. I've been in customer-facing positions helping organizations document their systems and develop solutions, and then served as a liaison between the customer and internal technical teams to develop and deliver solutions in an iterative, Agile fashion with continuous customer review and feedback.
I employ this general process for analyzing systems and developing solutions:
- Understand what the customer thinks the problem is.
- Understand the existing system through discovery, interaction with SMEs, and data collection. Map, characterize, and document the existing system AS-IS until all parties agree that the understanding is correct
- Understand what the problem actually is. Design a business solution to address the desired TO-BE state until all parties agree that the solution will provide the desired benefit.
- Design a system or a modification that will enact the solution.
- Implement the solution.
- Verify the solution.
If the engagement involves creating a new system steps 2 and 3 are a restatement of the DMADV (Define-Measure-Analyze-Design-Verify) process of design, which is also referred to as DFSS (Design for Six Sigma).
If the engagement involves improving an existing system steps 2 through 6 are a restatement of the DMAIC (Define-Measure-Analyze-Improve-Control) process.
Every project may not explicitly involve every step. If a step is not explicitly involved, however, it is surely completed implicitly, outside of the context of that project.
The nature of the business need is understood by analyzing a system's inputs, processes, transformations, decisions, outputs, and indicators. Proper identification and characterization of these elements will usually suggest the outline of the solution.
In theory it's possible to reframe the business need in terms of opportunities that become apparent through processes like this. A classic business school example is Xerox retargeting their mission from making copies to managing documents. Most of the engagements I've supported were pretty well defined, but smaller transformations and adjustments do happen and one should be open to them.
Subject matter expertise is applied to the solution either by the analyst or by internal or external specialists interviewed by the analyst. The entire system, along with the knowledge of the various SMEs, is then documented and that document is updated and circulated with feedback until all parties are sure that the analysis team has a correct and complete understanding of the system and the problem.
Once this is complete the solution can be proposed using the tools with which a team or an individual is most comfortable, new tools created or selected for the purpose at hand, or a combination of both.