Project Management

Keeping Requirements Outside the Project for Productivity

From the Eye on the Workforce Blog
Workforce management is a key part of project success, but project managers often find it difficult to get trustworthy information on what really works. From interpersonal interactions to big workforce issues we'll look the latest research and proven techniques to find the most effective solutions for your projects.

About this Blog


Recent Posts

Project Site Design For Stakeholders (Part 1)

Keeping Good Workers According to Experience and Research

Help Yourself by Helping Your Team

Countering the Most Difficult Strategy Implementation Obstacles

Resource Problems in Org Change Management (RPA)

Recently I wrote an article with a couple of ideas for tweaks to the waterfall method that makes it a little more responsive to business needs and possibly a little less stressful for the project team. One was to overlap phases and the other was to break up project scope into smaller bites and run smaller projects more often.

I mentioned a third option that would be covered later - and this is it!

First, though, let's deal with a basic preliminary question. What does this have to do with workforce management, the subject of this blog? Managing requirements well is a predecessor to managing the project workforce well. When requirements are clear, stable and complete, your project workforce deals with fewer problems in later phases. Your workforce is more productive generating fewer risks and issues.

With that known, consider now a common occurrence: A project is initiated and eventually a requirements document is created. Think about this a second. The project starts, meaning it is assigned a high-level scope, an initial budget and expected timeline, and only then are actual specific requirements defined. We all know that when details are defined, there are all kinds of discoveries. Some of these discoveries lead to additional expense, duration, dependencies, and resources. Some discoveries force the requirements definition itself to be extended unexpectedly.

What if requirements were handled a different way? What if they were managed mostly outside of the project itself? What would that tactic be called?

Keep Requirements in a Separate List to be Processed Continuously

Consider the situation of a web site that is used by customers. The customer service group and sales group that support the site are endlessly looking for improvements. They want one function faster, another function upgraded, a third function added. They have these needs all the time, not just when a project is in progress.

Why don't they keep a list on their own?

Once they have such a list, they can assign priorities to the items in the list. They can add impact ratings, where the improvements that will bring the business benefits will become more obvious. They can add an indicator to show whether the listed item is new as opposed to "mature" or "stable" (better understood, articulable and justifiable by groups keeping the list).  

All this kind of information is their own decision. No project is needed to manage it. Even better, the groups who keep this list can filter on the mature/stable items, then choose high impact/large benefit items and use that as the basis for the business justification for a project.

The groups maintaining the list may not know the true cost of getting the work completed at this point. For example, they will not have contacted the technology group for sizing. But with a very precise and mature list, sizing will proceed quickly.

In the project, scope (based on the requirements selected from the overall list) is already in a near-complete state. Requirements gathering is much less risky as the business requirements documentation is built out quickly. Additional related requirements ("non-functional" for instance) can be added relatively quickly from control partners like legal, compliance, operational risk management.

Want to level up? Assume that the decision has been made as well to abandon large annual projects and to go with smaller continuing projects that have quarterly releases, as discussed in my article. Each project can take a subset of the requirements, basically taking the highest priority at the time, creating a continuing flow of the most needed functions being released.

Now that is managing requirements for better productivity!

Posted on: November 20, 2018 10:30 AM | Permalink

Comments (11)

Please login or join to subscribe to this item
You bring up some good and important points Joe but sometimes it is difficult and things flow in a different way.

Good points, Joe And certainly segmenting the delivery schedule into prioritized buckets will provide tangible value to the business and organization. By doing this, we are setting up for positive working partnerships and a mature delivery model as a go forward strategy within the organization.

Joe -

this model is effectively the product or value-stream rather than project-centric approach whereby information such as requirements is persistent. In such case, a product backlog lives forever or at least till the product is put out to pasture.

Projects then are merely funding envelopes for releases of the product...


They should have a better name for the product backlog after the product is in production. I guess it effectively becomes an issue log (ie. maintenance).

Guest, it can work in most industry.

Good points. Thank you for sharing

Dear Joe
Interesting your perspective on the theme: "Keeping Requirements Outside the Project for Productivity"
Thanks for sharing

I had a feeling that an adaptive development approach would be better suited to this project

Please Login/Register to leave a comment.


Music is the medium. Passion is the message.

- Herbie Hancock