Traceability enables optimal design decisions for your program

 

In our last post Become a Master of Your Domain I talked about the four major domains of the Design Authority (DA) V-model and how together they help ensure that our systems are designed as architected, and that the systems are implemented as designed. Throughout the V-Model, and I will discuss each of the domains in later posts, we have a key weapon in the DA’s arsenal: Traceability.

 

Managing design decisions in a program across multiple work streams is a tough task. Even knowing which critical decision trade-offs are being made is a challenge. Furthermore, subtle design trade-offs between local (work stream) and optimal (program) optima cannot be easily understood by a single mind. We humans tend to search for options until we find one that satisfies a minimum set of acceptance criteria, we are not very good at optimizing choices in complex programs, and if in addition to complexity, we have tight couplings between work streams and functionality, we are at high risk of delivery failure!

 

How then, to maintain confidence in delivery, do we ensure we know what trade-offs are being made, what impacts these decisions have on other work streams, or if these decision satisfy not only a local, but a global program optimum?

 

We know the Design Authority has the objective to ensure on a proactive and continued basis, that the design decisions taken by each work stream in the program reflect the needs of the customer. We also know that design evolves from the initial definition of requirements (and for those of you agile gurus, yes, user stories and tasks are requirements!) for a given system, through a series of iterations following a top down (demand-driven) approach, to a firm system configuration ready for implementation.

 

Therefore, from a DA perspective, traceability is a must have program requirement in terms of increasing transparency and delivery confidence.  The image below depicts the key traceability layers, from business strategy to capabilities all the way through to test results:

For this post I have listed benefits to your program from investing time and effort in implementing traceability:

  • Traceability allows the program to demonstrate to the business that the requested capabilities have been implemented.
  • Traceability enables coverage analysis and gives the program and understanding of how and why the system meets the needs of the business
  • Traceability facilitates requirements change management and enables impact analysis on changes to projects already in progress
  • When using a proper requirements management tool, traceability allows for reuse of requirements and test cases
  • Understanding traceability enables optimal iteration planning
  • Traceability helps ensure that developers are not creating features that no one has requested
  • Traceability supports resource management – the limited time and personnel is focused on the most important areas in development and Validation (doing the right things) &Verification (doing things right) activities
  • Through traceability the program can ensure that all requirements are correct and included in the test plan and the test cases
  • Traceability helps reduce rework by helping ensure all work is against current requirements, and that requirements are complete
  • Traceability helps simplify maintenance by mapping changes to other, potentially impacted parts of a system
  • Traceability provides the data to help us “optimize” rather than “satisfy” when making design trade-off decisions.

In our next blog I will discuss the perennial issue of rework, understanding the causes and how this can be managed and reduced for the benefit of your program. Traceability will more than pay for itself by helping us reduce the rework cycle and all those negative dynamics that arise from expensive rework.

Andre Michel Vargas

Advertisements
Post a comment or leave a trackback: Trackback URL.

Comments

  • Ravindra  On June 16, 2011 at 3:16 am

    Great insight in Program Delivery effectiveness. I must say with my personal experience in a large and complex program with highly demanding client that DA and traceability makes the Program delivery strategy very structured and effective.

    • andremichelvargas  On June 16, 2011 at 2:01 pm

      Thank you, I am mostly amazed at the short term decision to not do traceability because of the upfront perceived “extra” effort. Throughout the program, DA methods work in orchestration to reduce risk and ensure long term quality. I am already planning the next blog where I’ll use a well know system dynamics model to understand the impacts of rework on programmes, so that I can then use these post to build a case for DA in programms 🙂
      Watch this space!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: