Know what you’re about? You have to know what is required to succeed!
By: J. Deems
Tags: Innovation, Project Management, Projects, Leadership, Management

Your organization is depending on you to shape the future. How can you do that if you don’t even know where they want to go or how they expect to get there?

Have you ever read a recipe where the heating instructions and cooking temperatures were omitted? I recently tried to follow a beef stew recipe where the only guidance given was to ‘warm’ or ‘braise’ an item. I was at a bit of a loss given that this was the first recipe I have attempted since before COVID-19 was a thing. I had an unmet requirement and it almost derailed the whole project! According to the Project Management Institute and the Project Management Body of Knowledge (PMBOK) 6th edition, there are eight types of requirements. Understanding these types of requirements, how to gather and document them, and what happens when one is missed can have a significant impact on the success of your organization. After studying these for a moment, see if you can determine what type of requirement cooking temperatures are in a recipe.

Organizations may vary their terminology from one industry or region to another. For the purposes of this discussion business requirement will be used to describe anything which aligns to a strategic objective or stakeholder need. The actions needed to fulfill a business requirement are known as technical requirements here, though some organizations may refer to them as functional requirements. You will see why technical requirements is the preferred term as we define the requirement types. The PMBOK guide 5th edition defines eight discrete requirement types while the 6th edition smartly nests functional and nonfunctional requirements under solution requirements. The eight classifications now read as (descriptions are my own):

Business requirements: the needs of the strategic undertakings. These requirements will derive from, and define, the goal of the project. An example would be if your business solution is to implement a client-facing Secure File Transfer Protocol (SFTP) repository. The business requirements may be to provide clients a way to safely provide documents to support an operational activity and standardize the way your organization receives and organizes client files to improve processing efficiency.

Stakeholder requirements: this is where those impacted by the project will have a voice. Following along with the SFTP example, lets assume the call center functional manager tells you they have a 75% remote staff who work on the virtual private network (VPN). They need to be able to access the repository while connected to the VPN. This can be captured as a stakeholder requirement and will also transfer over to functional requirements as we will see below.

Solution requirements: look down at your legs. If you can see your legs you need some pants, my friend. Those pants will have a waist and length measurement. That is the solution requirement for covering your legs with chinos. In America, most doors are eight feet tall. That is a solution requirement which has been standardized to make designing, manufacturing, and building easier. There are two types of solution requirements sub-categories.

Functional requirements: what the features of the product or service will be. In the case of the SFTP repository solution, the product will support all security and authentication functionality of SSH. There’s usually an action related to functional requirements. Now you can see why it is good to differentiate between technical requirements as an overarching category and functional requirements as a sub-category of the solution requirement. Conforming to regulatory guidelines may fall into this category. An example of this could be the accessibility features required by the Americans with Disabilities Act (ADA).

Nonfunctional requirements: these are items which are important, but may not actually do something. Having a nice UI/UX for the login page is a nonfunctional requirement. If a nonfunctional requirement is not met you will likely have a lot of upset people, but the product or service could still be meeting all of the functional requirements and operating as expected.

Transition and readiness requirements: these are very important items which will accommodate the transition needed to complete your project. These requirements will likely revolve around training, data conversion, temporary functionality and anything else needed to support the transition from as-is to the future state.

Project requirements: these requirements will inform the project leader of what needs to take place and when in order to satisfy the project. These will include constraints from enterprise environmental factors or organizational process assets. It is a good idea to work on these requirements with other people in your PMO or other project leaders if your organization does not have a PMO. This will help you understand any resource constraints that may exist if you need to share resources such as technical teams. The project requirements will also be informed by other tiers within your organization. Let’s suppose the SFTP repository project is due to a regulatory decision. That decision will provide you with some milestone dates for certain audits as well as dates for a transition and go-live.

Quality requirements: these define how project deliverables will be verified as successes. The SFTP project will need to pass security audits. Your pant’s zipper needed to have a certain number of like zippers tested during manufacture. There’s probably even a quality requirement for how many pepperonis had to be in the first hot pockets prototypes. An easy definition of quality requirements is the acceptable measure of conformance to the above stated requirements. These requirements will help you stay in the iron triangle of cost, time, and scope. Conforming to the quality requirements will also make all of your stakeholders feel very proud of the effort their teams put in or the commitment they made to the project success.

Project and quality requirements are not performed as a part of the business analysis effort and are the responsibility of the project manager. The requirements management process begins with business analysis and a needs assessment. This may begin at any level from portfolio to program or even within each project.

It is important to know the difference between business requirements and stakeholder requirements. While the business requirements will likely be set by stakeholders, they are discrete. Before your project or program was created, the strategic plan which led to your project or program existing was established. The strategic leaders who developed this plan will likely be stakeholders or be represented by a stakeholder in your project or program. To give you a kindergarten illustration, it is the business requirement of the board of education that all kindergartners must color a picture for their mother’s. A stakeholder is the student and that stakeholder requires paper and crayons be provided to meet the business requirement. They may also require juice and cookies to support their creative energies. The business requirements will tell you what your organization wants or needs to do. The stakeholders will set the scope and tell you what they need to succeed.

Now travel back in time to that recipe without heating temperatures or directions. What type of requirement do you think they missed?

In part two we will take a deeper look at gathering requirements. Gathering requirements is an art form as you’ve got to inspire a group of very important people to be where their feet are and open their minds to imagining what is wanted, needed, obligated, and demanded from themselves and all the groups they represent. Warm up your verbal judo and get ready to grapple!

For more or to get in contact with me, visit www.jarreddeems.com or www.jarreddeems.com/blog. This article was also published here.