PM Articles > PM Perspectives > Holistic Methodologies: Odd bed partners (Six Sigma and PMLC/SDLC), but Harmonious Relatives

Holistic Methodologies: Odd bed partners (Six Sigma and PMLC/SDLC), but Harmonious Relatives


Voices from Unexpected Places, Part 1

Everyone has an opinion, but not all opinions agree and lead you to the same conclusion. Who do you listen to get to the truth? What is best for the outcome of the project scope and business as a whole? The answer may be simple on the surface—your sponsor is the governing voice. Since your sponsor is giving you the overall goal for the project outcome and your success is measured by their satisfaction. In many cases the answer is as simple as, "Just ask your sponsor." And if that was indeed the whole answer, we could conclude this article right here.

The sponsor may be able to provide the success criteria and end state, but they may not be able to tell you what is the most effective or efficient method to deliver. The sponsor may be less interested or unaware of the impact the product or process will have on actors or other business processes.

However, requirements gathering and validation—as any seasoned business or systems analyst will tell you—are both art and science. Like mastering golf or chess, it takes many years of trial and error to become proficient. In this two-part article we will explore:

  • the various sources of requirements;
  • how those sources can be used to support requirements gathering, and to identify and resolve differences;
  • what tools can be used to evaluate the supporting data;
  • how to interpret what the data really says;
  • why requirements sources are not always people, and can emerge from data, process, and corporate culture.

Requirements Gathering and Evaluation

We gather requirements to ensure that the product of the project will have an agreed upon set of features that can be tested for quality, adherence to a standard, and completeness of functionality. Additionally, we are meeting the needs of the customer and or sponsor along with providing a measure of success for the product of the project. We use requirements to uncover functional and nonfunctional components that are critical to the quality of the product, the capability of the process, or the customer's needs. We use those requirements to evaluate the product during testing. The results of testing provide an adherence to the requirements to obtain a set of completion criteria to exit the project and deliver the product to the customer.

How do we know when we have enough requirements or the right requirements to start work on delivering the product? There is no silver bullet or black-and-white answer to this question, but one truth that has worked for me is correlation between various sources backed up by normalized data. Using progressive elaboration to zoom in to obtain the detail during the design phase is another well tried and successful method. Your requirements may not just come from people; the process (Voice of the Process, or VOP) and its listening posts create data. The VOP quite often contradicts the human voices. (Even when those human voices are actors within the process.)

Project Management Tree Swing

I think we have all seen this cartoon by now and it needs no further explanation. It is an iconic representation of how opinions can cloud what the customer truly wants and what you think you are tasked with delivering. In this case, validation is a necessary but an often overlooked step.

What if the customer is not the only stakeholder and the core tenet of the customer is always right does not apply? In some other cases the customer is your sponsor, but the customer may not always know what is right for them. Let's explore the sources of requirements to get a better understanding of quantifying their value and potential pitfalls.

A Word of Caution before Proceeding

There is a risk of analysis paralysis: spending too much time gathering requirements when there is enough known to move the project forward. If you are using the approach of progressive elaboration throughout your requirements gathering, you have to be cautious that you have the right high-level requirements to begin with, or you could end up solving the wrong problem, resulting in building the wrong product.

Once you have elicited requirements, you need to make a judgment call regarding how controversial the requirements are, especially if those requirements don't support the views and opinions of the sponsor or leadership team. We discussed the use of Force Field Analysis in an earlier article {Stakeholder Risk Analysis} to identify and categorize enablers and detractors to a project or idea. Customer or stakeholder segmentation is another factor to consider when evaluating input from various sources, for example, when leadership has a different opinion about the requirement than the person doing the work. Leadership may know something the actor does not, or they may be oblivious or disinterested as to how the work is being done.

You may also have to evaluate how the culture of your company can or will embrace change, which comes out of delivering those requirements. Your experience will also tell you how to place a bias on the validity of the source and who or what to trust. These components are learned solely through experience and your own instincts.

Let's discuss the sources and how they can be used to help you make those judgment calls.

Stakeholder Influence

Stakeholder Influence

Stakeholder Influence

Stakeholder influence is another critical factor regarding who should be providing the requirements and how those requirements are weighted. In my experience as a project and program manager, one of my key roles is to protect the project from external or other stakeholder influence, which may have a detrimental impact on the outcome of the project t or design of the product. Within your stakeholder analysis it is important to identify who all the players are and agree with your sponsor about which group they fall into and their sphere of influence on your project.

Core Team

The core team will provide influence on the technical design and delivery of the product. They may also own the operational support of the product once in production. You have to be careful that this group doesn't hijack the overall goal of the project or force you into a technology design that is not supportable. I have come across many instances in my experience where engineers have wanted to use a new emerging technology to further their experience versus what is supportable as an operational product. (Also known as "Shiny object syndrome.")


Many of the industries we work in have some compliance oversight -- often some professional or governmental body that sets rules which we have to work within for a safety or regulatory requirement. These often mandate the requirements which go into the design or usage of the resulting product or process.

Impacted Stakeholders

Impacted stakeholders are often the group(s) of individuals who own the operational support of the product such as help or support desks, down- and upstream systems, and other departments that interact with the primary customers or suppliers

Other Stakeholders

These are individuals or teams who are not directly impacted by the product or process change outcome of the project, but may be indirectly impacted. They may play a role in another part of the process that has a knock-on effect. An example could be that your project takes a different technology direction, which in the future may isolate their product and force them into a tactical or strategic direction change.

It is a careful balancing act between what is right for the customer versus what is right for the company as a whole. There is also the challenge of managing the personal agendas of powerful influencers who could be part of the other stakeholders who may want to hijack your project for their own needs.

In the second part of this article we will explore the sources and their interaction in more detail.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.