Technical Discovery: ... in a nutshell

Technical Discovery ...in a nutshell

Contents Disclaimer What is technical discovery (definition) Why is needed (purpose) How do we go about it (process) What does it produce (products) What if we get it wrong (risks and impacts)

Disclaimer This deck was put together to capture in simple terms (in a nutshell) what technical discovery is. Its content is targeted primarily towards people from non-technical disciplines (who are involved in the discovery process of a project) with a view to educate them on this subject so: technical discovery is not a “black box” to them they can appreciate its importance and how it affects and is affected by the other streams in the discovery process The material is deliberately not branded, to facilitate easy reuse in whole or in parts for derivative works. To this end it is distributed under a Creative Commons License: Creative Commons Attribution-Share Alike 3.0 License . Under this license you have to attribute that the derivative work is based or using parts from this deck. An acknowledgement with my details as per the footer of the deck would suffice. If you reckon this license is not suitable for your purposes, you may contact me to explore alternative licensing options.

Technical discovery - definition Technical discovery is the technical stream in the discovery process in a project. It happens in parallel with other work streams (e.g. information architecture,creative and visual) in the discovery phase of a project. Technical discovery is the activity of identifying the problem context i.e. the business functional and non-functional requirements, the business system landscape (systems, owners, users, processes, interfaces, policies), and any other factors including scheduled changes to the above during the course of a project, assumptions and available technologies that altogether serve as constraints (either soft or hard) in shaping the solution to be delivered which must fulfill both constraints and requirements. The exit criterion for technical discovery is gathering of sufficient information to produce a technical approach which gives the direction for the architecture of the solution. The architecture turns into more detailed design during the build phase. All discovery streams together should result in a sufficient understanding of the problem to be solved and the constraints around it, to be able to enter the build phase of a project.

Technical discovery - purpose The purpose of the technical discovery process is to: identify requirements (both functional and non functional) of architectural significance. prioritize and balance requirements (i.e. creative vision: what we want to achieve vs. technical capabilities and constraints: what is possible (scope) within timeline and budget). feed into the planning process an initial view on scope, tasks, dependencies and estimates. produce an initial feature matrix and map this to a program road map, envisioning the development and growth of the solution, in line with business strategy and objectives.

Technical discovery - process Technical discovery is about investigation of the 'big picture' and analysis of the rationale and principles underpinning the findings. The following methods are typically employed: workshops with key stakeholders i.e. project sponsor(s), executive management, involved departments (communications, IT, finance, marketing etc.), third party vendors if applicable and primarily end users. collation of documentation provided about systems (own or third party), processes and policies. Where direct documentation is not available indirect methods are used e.g. analyzing server logs /analytics, reverse engineering interfaces of existing systems, reviewing existing code bases as appropriate. The outputs of the above methods are assimilated into a collective view which defines the solution context and scope. Any gaps identified (known unknowns) must either be resolved through further investigation or working assumptions to allow the work to progress must be adopted. All assumptions must be communicated clearly and signed off by the client, as they may impact the project scope, timeline, costs and risks, affecting overall delivery .

Technical discovery – outcomes & outputs The main outcome of technical discovery is reaching a position where one or more solution options are proposed to the client, with enough level of detail and confidence be able to select one option and enter a build phase to deliver it. the duration, steps (inc. milestones and sign off checkpoints), costs and risks of the build are understood and agreed with the client. The key outputs of the technical discovery process are: technical approach / high level architecture document. It encompasses the big picture as identified during discovery and consists of multiple context and solution views from conceptual, to network topologies as appropriate. technical project plan – the path to be followed during build technical spike(s) / proof of concept employed to evaluate and derisk technology selection and integration

Technical discovery – risks & impacts A technical discovery can be incorrect (not correct analysis of assets, miscommunication with stakeholders, non validated assumptions) or incomplete (people or systems that should have been involved in the big picture haven't) The impacts can be: solving the wrong problem (deliver within constraints, but fulfill requirements captured vs. actual requirements). System is underutilized or abandoned. fail to solve the problem (solution is inappropriate / does not meet constraints /not viable) fail to deliver on spec, schedule, budget

Technical Discovery: ... in a nutshell

More Related Content

What's hot (20)

Viewers also liked (9)

Similar to Technical Discovery: ... in a nutshell (20)

Technical Discovery: ... in a nutshell