If you have been a project manager for any time at all, you probably have experienced competing demands from the sponsors for the project.  The sponsor is the person(s) who drive the scope of the project in conventional projects.  In some instances, the project manager may find that there are in fact multiple sponsors and the respective priorities of those sponsors may be at odds.  This is not the only difficulty to which the project manager must respond.

From the CHAOS study by the Standish Group, on project failures and success factors, we find the results below. This study analyzed 23,000 projects in 1998[i], of the factors that enable project success and failure.

A list of the top 5 factors from this study, demonstrate that importance of the interface between the project, the executives that are supporting the project and clear business objectives.  The top three alone are significant exchanges between the project the sponsor and the user or client. When we are not sure who the sponsors are, or which have the highest priority, we spend considerable time wrestling with the balancing of inputs to determine which of these conflicting views is the most important.

In scrum, we have a product owner that interfaces with our team, and this person brings the voice of the customer to our team. Not only do we have a single point of contact via the product owner, but we have the input from that product owner groomed; that is, analyzed, understood, and prioritized for the scrum team to generate the product backlog. The scrum master works with the product owner to make sure that this work is prioritized enough for the team to undertake and produce the desired results.  This prioritization and grooming before time to doing the work, reduces if not eliminates the wrestling match between sponsors when the work is underway.

The requirement along come with some burden, and that is what are true requirements and what are things posing as requirements that do not belong in this software product.[ii]

Far too often the literature on software quality is passive and makes the incorrect assumption that users are going to be 100% effective in identifying requirements.  This is a dangerous assumption.  User requirements are never complete and they are often wrong.  For a software project to succeed, requirements need to be gathered and analyzed in a professional manner, and software engineering is the profession that should know how to do this well.

Software engineers have an ethical and professional obligation to caution clients about these problems and to assist clients in solving them, if possible.  In other words, software engineers need to play a role similar to the role of physicians.  We have an obligation to our clients to diagnose known requirements problems and to prescribe effective therapies.

Once user requirements have been collected and analyzed, then conformance to them should of course occur.  However, before conformance can be safe and effective, dangerous or toxic requirements have to be weeded out, excess and superfluous requirements should be pointed out to the users, and potential gaps that will cause creeping requirements should be identified and also quantified.   The users themselves will need professional assistance from the software engineering team, who should not be passive bystanders for requirements gathering and analysis.

While agile has a method outlined for how to ascertain the veracity of the requirements and only work those that are understood, those that practice conventional approaches may not have this sort of process, which would include among many things. requirements reviews, walk throughs, mock ups and prototypes, focus groups and more.  These are not project management doctrine, strategies or tactics but more product and software development methods.  In instances where an organization or a project manager does not know of these approaches these types of activities are not included in the work. WE end up with a long list of requirements, some of which are not even requirements, and if we do not take proactive steps in the beginning

The product is built upon the requirements, and the quality of the requirements will have an implication on the final product.  The agile approach reinforces this thinking by requiring a product backlog be understood and prioritized, before any work starts in the sprint. Conventional approaches can take this same approach, but it is not part of project doctrine but part of a product development methodology.

[i] Jim Johnson, et al. 1998. ChAOS: A recipe for Success, 1998. Published Report, but the Standish Group.

[ii] Jones, Capers. July 24, 2015 Software Requirements and the Ethics of Software Engineering, page 3-4 Namcook Analytics