A Design Authority (DA) function mitigates against project issues such as stakeholder conflicts and implementation fatigue. Leveraging the DA V-model, mentioned in our last post (click here to see our model), ensures that the solution is designed as architected and the product is implemented as designed. The V-model focuses on 4 domains, or areas of emphasis, at different times in the program’s lifecycle. To fully understand the V-model, let’s take a closer look at each of these domains.
The Design Authority has 4 domains:
Architecture and Design Standards – In this domain, the DA develops the early-stage design methodologies. The DA leads stakeholders to agreement on architecture standards and high level design blueprints for applications, information, infrastructure, service management and security.
Throughout the program lifecycle, the DA conducts reviews, mediates design negotiations and communicates design decisions to ensure that the designs meet business goals and minimize late-stage changes to product requirements.
Requirements Engineering – In this domain, the DA establishes guidelines for requirements management and development. The DA works with business analysts to define processes for requirements elicitation, prioritize requirements and evangelize the importance of requirements traceability (a topic we will discuss in more detail in a future posting). The DA is also involved in the definition and execution of the requirements change management process. Effective requirements engineering facilitates impact analysis on changes to projects already in progress, reuse of requirements, phase/iteration planning, resource management (ensuring time and personnel is focused on the most important areas) and ensures onerous features are not created.
Functional Analysis and Validation – In this domain, the DA must demonstrate to the business that the requested capabilities have been implemented through:
- Validation of coverage – Doing the right job
- Verification of requirements – Doing the job right
The DA performs coverage analysis and understands how and why the product meets the needs of the business. The DA verifies that all requirements are correct and included in the test plan. Collaboration between the DA and the QA team will reduce rework by helping ensure all work is completed in-line with current requirements.
Design Integration Assurance – In this domain, the DA strives to avoid a common mistake–programs and suppliers focusing on the delivery of sub components rather than the overall design. Commonly, assurance of the overall alignment and integration of the design is left until later in the program. Integration assurance takes an end-to-end view of the design and uses a business perspective to ensure that the entire delivery will produce business value. The DA drives early integration assurance and mediates in boundary discussions between all workstreams. The DA’s focus on integration ensures that deliverables are assimilated with the business and increases the likelihood of achieving successful program outcomes. It also gives stakeholders and sponsors confidence that the program will meet the user’s requirements.
In future posts, we’ll discuss how the DA leads workshops, creates the right teams and impacts development processes to allow these domains become effective contributors to the program.
Joel Cervelloni & Andre Michel Vargas