Always Negotiate the Project Requirements

The traditional approach to project management is that you create a list of everything the project must accomplish, and then you craft a plan to deliver that list of things. That list is called the requirements for the project.

There is something reassuringly certain and fixed about the term “requirements.” But real life shatters that illusion pretty quickly. We could learn something along the way that means the requirements must change. Or someone could just change their mind as they see the system coming together.

The term requirements then is a bit of a misnomer – it might be more accurate to call them desirements to clearly emphasize that at the end of the day, almost everything’s optional.

In my work with clients, I view all requirements as negotiable. Experience tells me that by probing how much flexibility there is in the client’s goals, I can often uncover a better way to achieve them. There is always a point where the trade-off between the desired outcome and the cost of delivering it becomes uneconomic. This negotiation process is core to how I use the meta-problem approach in my work.

To pull an example from recent client work: my manufacturing client was dealing with a change order to a large custom-built project. If the change was to be made during the original build, it was going to delay our project by several weeks waiting for the extra component to arrive. Adding the component onsite instead had slightly higher costs in labor, but kept the project on track timeline wise.

Some requirements have knock-on effects if they are changed. I was fortunate to learn system’s engineering in grad school from former Secretary of the Navy Donald Winter. He presented a vision of System’s Engineering where a key part of our role was to manage those knock-on effects, since it can only be done at the system level.

Say you are designing a satellite and have a total weight budget. Those weights are initially divvied up between all the subsystems, and they become requirements for the subsystem teams. If one team really needs extra weight, that would mean other teams would have to make changes to accommodate.

The traditional approach to project management simplifies the juggling act (at least in terminology) by calling those allocations a requirement. We can still change the requirement by committee, which will hopefully allow us to design a system-level adjustment if we need one.

Non-traditional project management approaches like Agile instead design for a more flexible approach to work. When you don’t have a clear definition of the final product though, it is typically harder to recognize the knock-on effects as you adjust along the way.

I personally believe the best of both worlds comes from a thorough planning phase, and then incremental delivery in the context of that system-level plan. This naturally covers some of the gaps you will otherwise encounter in agile projects like issues around interfaces and security.

Regardless of how you manage your project, the key takeaway is to consider the cost of each requirement as you go.  Unless you get the committee to sign off on a change, you should do what was planned, but remember that throughout any project there is always a price point at which we will change our plans.