Archive for July, 2016

Requirements and Work Breakdown Structure

Posted on: July 30th, 2016 by admin No Comments

Scope, Requirements, and Work Breakdown Structure

The scope of the work and the requirements provide us with information from which we can build the Work Breakdown Structure or WBS.  In fact, even before we are able to start doing the work to build the expected results of the project, our work breakdown structure should capture the items associated with evoking, understanding and documenting the requirements.  We may (should) have one of the top levels of the work breakdown structure hierarchy that specifically address those items and things we should do when it comes to the requirements.  The decomposition of this portion of the project will ensure we consider all of the activities required to allocate both project time and talent to ensure the requirements gathering and documenting are given the diligence that this key part of the development of the product is due.  For example:


Example of Work Breakdown Structure for Requirements

That is not the end of the work breakdown structure.  The contents of the requirements documentation will also drive subsequent actions to deliver the product or project results.  In this way, the requirements will identify specific actions that must show up in the work breakdown structure.  For example, if our requirements point to software, then we know there will be elements of software development in the work breakdown structure.  The definition of the expected quality of the project delivery will identify quality assurance activities that must take place to ensure this objective is met, for examples think reliability and allowed failure rate in terms of parts per million.

The work breakdown structure is used to outline the way we intend to build the requirements, and then the requirements will identify specific actions that will be included in the work breakdown structure.  These two things are symbiotic; the work breakdown structure contributes to the gathering and understanding of the requirements by providing an outline of the things we must do to gather and document the requirements.  It also identifies dependencies (not a function of the work breakdown structure but the act of decomposition we learn these things) and securing the time and talent for generating these requirements.  Then the requirements help us to structure and define the things that must be done to fulfill those requirements.

If you want to build the requirements in an adequate way for the project, consider breaking down the work for building the requirements. This includes things like activities for finding and removing of the defects in the requirements and specifications before we start building the product in the project.

Sweet Iced Tea Please (requirements?)

Posted on: July 29th, 2016 by admin No Comments

I have spent considerable time in the south, specifically North Carolina.  My dad was retired Special Forces and closed out his career at FortBragg (we lived in SpringLake).  Those not from the south, or have not spent much time here, may not know about sweet iced tea.  Sweet tea is a wonderfully refreshing concoction, especially in the summer.  It is ubiquitous with copious flows from most restaurants.  Sometimes I go out to lunch with my family.  The wait staff comes to the table and takes our drink order.  My wife requests sweet tea.  My son requests water or some other drink.  Then I request sweet iced tea.  My family then gives me some good natured ribbing for ordering the “sweet iced tea”.  I explain, if I order sweet tea alone, the tea can come back directly from the tea urn (tepid) they will not have delivered what I want, but will have met what I have asked.  If they come back with a hot cup of sweet tea, they likewise have successfully delivered what I want.  In both instances, their effort will have met my verbiage, but totally missed the target, wasting their time and mine.  I would not like the results

It is like this also when it comes to requirements.  Without this detail, we rely upon assumptions other interpretation and perspective to creep into the needs or wants.  We open the range of possible interpretations when we communicate in this less than specific way.  Of course, there are probably times when we are less particular.  In those instances, our communication can be a little subjective, but we must be ready for the consequences.

When we are working on our requirements, we should think this way.  Where specifics matter, we should clearly and carefully articulate as precisely as we can to reduce the possibility of a misinterpretation.

Requirements and Technical Debt

Posted on: July 27th, 2016 by admin No Comments

I was thinking about technical debt in the context of our recent spate of requirements postings on the blog.  Technical debt, from my perspective, does not just apply to software.  We incur technical debt when we implement an easy solution in the short run, as opposed to the best overall solution.  In other words, we have sub-optimized the solution selected.  Experience suggests in many cases we opt to optimize around time at the expense of the best design solution.  This approach does not end at software, but anytime we defer taking the best decision about the product, opting for speed.  We then are on the hook for meeting the financial obligation (debt) that is due.

If we believe that technical debt is associated with any aspect of the product in which we make the trade-off between the optimal design solution and some other consideration such as time, you can see how technical debt has many areas of origin.  This can include things like the requirements for the product.

In more than one of the companies at which I have worked, the requirements documentation served as the basis for the customer documentation.  In some cases, the requirements documentation was held in little regard (email or word of mouth), and the subsequent customer documentation reflected this gap.  Over time, the customer expressed the belief that the product was way too complicated and noted how the documentation that came with the product did not match the actual performance.  With this connection between the requirements and the customer documentation, we can see how taking actions that produce poor requirements will have an impact on the customer documentation.  The poor customer documentation costs the company in customer confusion, additional time spent in maintenance.  You could argue that this cost is at least a portion of the technical debt associated with development decisions when it comes to the requirements.

Requirements and Decomposition

Posted on: July 26th, 2016 by admin No Comments

The customer can seldom articulate the technical details of the product.  The customer may define the product or need in terms of function and performance, but building the product from these documents will be extremely difficult or perhaps impossible.  We will need some type of document to begin describing in technical terms the product that acts as a bridge from customer language to technical language.

One of the companies at which I have worked had a document that described the subsystem interactions.  This was called a cross-functional specification.  The cross-function refers to the interactions of the many electronic control units on the vehicle that were networked together.  The document described how the system would achieve the goals of the project, identifying specific signals, particular communications requirements and performance expectations from the numerous components on the vehicle network.  This essentially apportioned the function (distributing specific responsibility) across the numerous components of the network.  However, this homegrown document filled a very necessary role in the development of the systems on the vehicle.  Specifically, this description of how the system would achieve the expectations of the project was a mash-up of technical and non-technical content, with enough technical structure to allow those that owned the detailed specification work to be able to write requirements that supported this system.

We do not need to build this systems description through homegrown requirements.  One such structured approach is the IEEE STD1233, 1998, A Guide for Developing Systems Requirements Specifications.  This document can either serve as our template or help us generate our own specific approach based on our application.

Defining the system in both non-technical and technical ways facilitates effective reviews of the intended design by both technical and non-technical personnel, meaning, the engineers and the customers.  We can and should review this document with the customer but also with those that are to create the detailed specifications (essentially a walk through).  In the case of the automotive manufacturer, those responsible for the detailed development of the individual electronic control units should be there to understand how the system is to work and their particular role in the performance.

This systems requirements document is the very headwaters of our decomposition of the requirements, all of which start from the objective and the scope statement for the project.  A systems requirement document can effectively synchronize the understanding and coordinate the work that follows.

Can Innovation and Continuous Improvement Coexist?

Posted on: July 24th, 2016 by admin No Comments



This question was posed by Tom Cagley on Twitter.  At first blush these may seem at odds or exclusionary, but perhaps not.  I know why it may seem difficult to be innovative while we are hyper-focused on continuous improvement activities.  A company that focuses on continuous improvement that tends to be incremental can occlude us from thinking creatively, laterally and innovatively.  However, it is not impossible for innovation to be a considerable source of that improvement.

Continuous Improvement

Consider the tier one supplier to an automotive company.  Original Equipment Manufacturers typically have cost improvement initiatives in place that cover the life of the product, the expectation the tier one supplier is constantly improving their capabilities.  These cost improvement targets may be a few percent per year.  In the first few years of production, it will be relatively easy to meet these objectives.  However, after years of reducing the cost by 6%, it will become difficult to achieve that 6%, think of the law of diminishing returns, and we have to think radical or innovatively to achieve the cost improvement objectives – or fail.  To hit this target we will need to think differently, innovatively, to achieve our goals.

I have worked at a company that set difficult targets for improvement from time to time. In these instances, innovation was required since the target was larger than could be achieved incrementally, and had a delivery date that was relatively in the short term.  However, I can say this company’s continuous improvement capabilities were not stellar, they did rely more on innovation than an incremental approach.


Corporate culture may impact our ability to innovate.  If our organization is set on achieving targets and holds little value for the uncertainty that may come with exploration and innovation, then innovation may be difficult.  If we have no time or fear failure, then we will likely have no time nor hold in high regard innovation.  Management must be patient and allow time for application of new strategies (techniques or methods) and even the failures that may come with that exploration – that, in my experience are intrinsic to innovation. 


Product type can also have a role in determining our approach to improvement.  If we build a consumer product and our profit margins on the product are low, we will likely not want to spend time that may not create the return on investment we require.  In other words, we cannot afford to take time unnecessarily nor mistakes that may go along with learning and innovation.  


Any company that desires to remain in business must find ways to continuously improve can do so without innovation for some time, but at some point to continue to make progress and improve, we will need to think differently akin to the law of diminishing returns.  The same equipment, processes, and methods, over time, will not improve the product or grow the company.  In my opinion, the successful organization must find a way to make both happen.  That may be difficult at times, but I believe both are possible; using the right approach for the circumstances at hand.

Toxic Requirements

Posted on: July 22nd, 2016 by admin No Comments

This blog post originates from Capers Jones LinkedIn comments about toxic requirements.  He posted a comment to a requirements article and brought up bloated requirements and toxic requirements.  I have never heard of the name “toxic requirements” perhaps that is uniquely Capers Jones identifier – I like it.  However, I believe I have experienced toxic requirements.  An example I have frequently witnessed would be requirements that are politically charged, not in the governmental sense but in the organization’s sense.  Have you seen the same set of requirements come in on many different projects? Each time the requirements are deferred or remove, yet these continue to re-appear.  These requirements may have little to do with the project objectives, but these requirements are the “pet” of some person or entity within the company.  We spend more time wrestling with these requirements than building the product. We will risk the significant portions of the project, specifically, those requirements that will actually achieve the objective and fulfill the customer needs.  In that sense, these requirements poison our intentions with the project and product.


Requirement Content and Prioritization

Posted on: July 20th, 2016 by admin No Comments

I have never worked on a project that took that approach.  In my embedded product development experience, the requirements grow as the product iterations are delivered, evaluated and tested.  The results of those evaluations and tests will impact the requirements.  There will be additions, subtractions, and alterations of the requirements.  We will update the requirements documents, paying attention to the configuration and change management issues.

In the automotive world, we can see a steady and incrementing capability and feature content of the product both hardware and software  The product often starts off as an incarnation with few features and little capability or reliability.  The next iteration will have more of the feature content (additional requirements) and perhaps increasingly hardened hardware.  The hardware hardening will have its own growth plan with increased features and capabilities each with a new part number.  The final incarnation of the hardware will be from hard tooling and from the production processes.  The final incarnation of the software will include the prioritized feature content, perhaps all of the features but occasionally, due to time and budget constraints the lower level features may not be available. This iteration of the product will also be tested in many dimensions (for example – environmental, reliability, component and systems integration as well as fall-back modes).

Each iteration on the way to the final instantiation of the product is a review of what was built, specifically, the test and evaluation results. This test and evaluation of the iterations provide the feedback loop driving the design direction based on the discoveries.  The documentation and drawings are updated, and the next iteration of the design and documentation updates.  This goes on until the product is ready to move to launch or the project budget is busted.


Requirements, Stakeholders and Stakeholder Management

Posted on: July 18th, 2016 by admin No Comments

Our project must balance the input from a myriad of people that are associated and contribute to the project, along with those funding the project to be successful.   To be able to do this, we will need to understand our stakeholders and their perspective.  Some of our the stakeholders will add requirements, support existing requirements or even contend some of the requirements.  Their perspective can be thought of in a variety of ways which we list below.  We will need to balance the inputs we get from the myriad of project stakeholders against the constraints of the project (time and money) and the success criterion of the project

Experience suggests considerable time can be spent sorting out inputs or requirements from sponsors and stakeholders.  I have personally been involved in projects where the clock ticked while the project manager and stakeholders and sponsors debated a certain course of action – effectively idling the rest of the team.  This comes at great cost to the project schedule, and I was glad I was not the project manager but sad to say I was part of systems engineering for the project.  The identification of the key participants and areas of responsibility as well as a clear escalation plan necessitated a global conversation to determine the appropriate course of action would drone on and on.  The larger and more distributed the organization, the more important it is to identify those key participants, and more importantly, those things that may distract our team from the mission of completing the project.  Of course, some items should cause a project to slow down, and may necessitate significant and prudent discussion on the course of action with regard to the specific requirements.  However, these occurrences should be the rare exception.


  • Internal / External
  • Supplier / Customer
  • Direct / Indirect
  • Real / False
  • Continuous / Intermittent
  • Severe / Cursory
  • Correlated / Inverse


This contrasting perspective or view of the potential stakeholders can help us consider the range of possibilities of stakeholder involvement and the requirements or constraints they may represent.  For example, the customer stakeholder’s input is likely more valid and has more weight to it than a false stakeholder.  The project manager and team should actively determine those impacted by the project and not just the sponsor.  The ultimate goal is to understand determine the perspectives that really matter for success and find ways to manage the often conflicting inputs.  To understand we can use tools such as:

  • Power / Interest Grid
  • Stakeholder Analysis Matrix

I have seen somebody post a lengthy discussion on the politics of project stakeholder management on LinkedIn.  It was received with a certain measure of ridicule.  However, projects are executed by people.  People are not fungible, and at times are not perfectly predictable.  They come with biases, and experiences that can greatly help aid the project or create a great chasm between the project objective and what is actually achieved.  To that end, understanding, balancing and monitoring these inputs are required, along with processes in place (such as a decision escalation process) by which all will be governed are necessary.

The Power of Do, Do, Do

Posted on: July 15th, 2016 by admin No Comments

We take a break from our requirements management run for this blog.  I was talking to an executive about some training for his organization.  He wanted the training to focus on action, on doing (he, in fact, said do, do, do).  He emphasized this very clearly and repeatedly, the action portion of continuous improvement.  This has led me to reflect on my experience.  To be sure we know that we can improve ourselves and our companies through constant learning.  However, learning on its own, will not improve your lot or your companies lot in life.

It is not enough to learn something new if we do not apply this new learning, the learning was an academic exercise.  Learning for the sake of learning is a good thing.  However, you could argue that the ultimate goal of learning could be to help you set and achieve your goals or the goals of your company.  It can be difficult to find time to “do”.  Breaking our old habits and actually applying this new learning can be difficult. There is an old idiom, old habits die hard.  These old habits can impede our application of the new learning.

It is not just old habits that can curtail our execution or the use of this new knowledge.  Sometimes it is difficult to start the application of the knowledge.  We have to think about our work differently.  How can we employ this new skill set?  Often the difficult part is just starting, and perhaps our employees do not really know where or how to start.  The truth is, we need to apply this new learning as quickly as we can to begin gaining experience and confidence regarding the application of the new learning.

This executive knew that training the employees of the company is really only the beginning of our improvement.  If we do not apply what we have learned, then this investment will not be a solution for improving the company.  We need real and tangible action to happen post training.  This executive knew this.  Follow up on the training with hard execution and additional learning through trial and error drive our familiarity with the topic and the methods.  This also improves our confidence, reduces reticence and drives additional learning.  In this case, post-training the executive decided there should be a series of projects applying the tools and techniques of the training.  These projects would be reviewed by the teams to drive the improvement.

Requirements Evaluation

Posted on: July 13th, 2016 by admin No Comments

Requirements Language

As we collect requirements we are going to need to perform some sort of evaluation.  We know the attributes of good requirements, now we will compare those attributes against the documented requirements.  However, we will not stop our evaluation at the type of language. We will extend this evaluation to other areas that can cause difficulty for the effective and efficient development of the product.


We are likely to have multiple stakeholders and customers that will drive the end product expectations.  Experience suggests this multiplicity and diversity of input can put the product requirements at odds.  In other words, some requirements that conflict with others and customer prioritization of the requirements may also be in conflict.  We will then need to juggle the requirements that make it to the final product and further refine those; specifically, what appears in which instantiation of the prototype or product iteration.  To do effectively, we will need to balance stakeholders as well as their respective priorities against time, cost and risks to the project.


Our evaluation efforts should find conflicting or contradictory requirements. These are opposing requirements that may be born out of the variation in our customer’s use of the proposed product or even the stakeholder’s perspective of the product.  We will talk about stakeholders more in the next blog post.  We will use tools like Quality Function Deployment and Pugh Matrix to help uncover and understand these conflicting requirements.

Technical Dependencies

The evaluation also allows us the opportunity to understand the technical dependencies of the requirements.  We will not only weed out what does not belong, we will also understand the interactions of the various requirements as it is related to the development of the product.  This provides the development team with learning opportunities that will help in the planning and the development of the product.

Subscribe to our Newsletter

Subscribe to our Newsletter
Email *
Single Sign On provided by vBSSO