Assess technical feasibility and quality
The risks of poor technical planning
Inadequate technical planning can slow progress down in the early stages of the product and completely cripple a product in the late stages of maturity. Problems stemming from poor technical decisions and a lack of quality strategy get compounded by the number of product teams actively working on the code base. It is imperative to set standards early and monitor risks. Unlike product-market fit, inferior technical decisions primarily incur monetary penalties with the product often requiring costly rework. When effectively applied, risk management strategies for technical feasibility and quality drive accurate estimates, reducing the amount of rework and financial uncertainty.
Conceptual, logical, and physical architecture diagrams help eliminate ambiguity around technical design decisions.
Conceptual
Logical
Physical
When thinking about technical feasibility, evaluate if the chosen technology is mature enough to solve the problem at hand. Typically emerging trends are hype, lacking practical application. The team needs to determine if the effort is understood sufficiently to warrant an estimate and whether the investment is justifiable to proceed with the proposed solution. It is easy to overengineer technology, and it is extremely challenging to make things simple. Assuming the solution passes the above smoke tests, review the technical prerequisites next.
For example, machine learning can introduce massive efficiencies into labor-intensive processes, but historical data is necessary to create effective models. Many organizations dive headfirst into the capabilities of technology without checking off the prerequisites.
To effectively quantify and manage technical decision-making risks, evaluate the domain in context of architectural design, technical process, and realistic reach.
| CATEGORIZATION | EVALUATION |
|---|---|
| Architectural | Is technical documentation available? Is the architecture defined? Are workflows understood? |
| Technical | Are automation bes practices available or under consideration? (Review automation, testing strategy, build process, environment provisioning, etc.) |
| Realistic research | Are milestones set in a realistic manner? Can the problem be broken down into manageable chunks? Is the plan to use micro-launches versus a big bank for the release strategy? |
Effective estimation techniques include top-down, theme-based estimation for roadmap planning, and bottom-up estimation for sub-quarterly release planning. Note that bottom-up estimates decrease in accuracy the larger they get.
For example, a top-down estimate of $10 million is created for a practice management product for healthcare practitioners. The estimate assumes a roadmap of eighteen months includes multiple releases to market, multiple product teams, no finite feature set, and a prioritized list of opportunities discovered through a service design exercise.
The pilot release for the same product is bottom-up estimated to take five months (e.g., allocating $600 thousand for the pilot) with further spend gated by validating product goals via analytics. Once the pilot releases, the team reviews the overall roadmap, reworkshops priorities, revises estimates, and plans for the next release (assuming the business opts to continue investing). If the pilot fails, the business saves the remaining $9.4 million.