The Challenge of Requirements

"What is this project about?" That's the million dollar question, but beneath the surface is a complex web of detailed requirements for the project.

This post is about project requirements. I will gear my thoughts around "system requirements", since I am currently working on a highly technical project where system requirements are critical. However, I want to address the difference first - if there is one.

On a highly technical project, the requirements naturally are...technical! The challenge, though, is in connecting to the things that are operational - and disciplining the whole ecosystem of the project around that scope.

Here are only some of the challenges in doing this:

  1. Certain things are already developed while others are undeveloped. Technical readiness, though, is only one input to priorities and scope.
  2. There can be MANY stakeholders...and they need to be prioritized. Stakeholders can have their own agendas, or a peripheral interest...and it is the project manager's job to sort it all out.
  3. Technical thinking needs to be separated from management thinking. For example, technical thinking considers risks only of a technical nature, such as technical glitches. However, there are strictly project management risks, such as shortage of money, lack of synchronization across stakeholders, lack of SMEs, etc.
  4. Technical people are often in management roles, making communication and understanding difficult. This often results from people being promoted to management roles and higher responsibility based on demonstrated technical skill.
  5. In order to maintain momentum on the project, higher level management support is needed. This requires a strong business case for the project that can carry it through times of confusion and questioning.

So how do approach all of these challenges and more?

A great approach, I find, is the project management concept of progressive elaboration, which I first learned when I was preparing for my PMP exam. In short, we acknowledge that not all of the requirements are available up front. Therefore, a lot of the project management work focuses on gaining clarity, as the project progresses, on the requirements for the project.

Progressive elaboration requires a clear high level understanding form the beginning. With that understanding and agreement among the stakeholders, you can move the project forward and elaborate on requirements at deeper and deeper levels, as they become clear. However, it is critical that you have clarity up front, at least at a high level, of the vision for the project.

As you and the team feel your way through to great levels of clarity, everything requirement that arises needs to "qualify" based on connection to this highest level of vision for the project. It it does not, and stakeholders still want it, it should be considered to be out of scope, and therefore a change of scope is required. Otherwise, it should be discarded, or if it fits within the scope, it is added as a new point of clarity that is within the scope, vision, and purpose of the project.

The more technically complex your project, the more you will need to allow progressive elaboration of the requirements take place. Accept that you will not and cannot know all of the requirements up front, and therefore you need to plan to allow those requirements to unfold as the project progresses. You can best manage this processor if you clearly establish higher level requirements that set the scope of the lower level requirements that will unfold. Your work will be in providing discipline to the greater project team in this evolving requirements definition process.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>