How to deal with constantly (~daily) changing requirements?

Question

I see a number of similar links, but none seem to have a solution, mostly "they shouldn't be doing that"'s. I agree, but please, read on:

Scenario: 800K pages of documents, narrative(e.g. emails)/bank statements/legal (e.g. options agreements). We are a small team, with only 2 investigators (1 of whom is primarily responsible for production), 1 financial person, and 1 legal person (along with some admin assistants and outside specialists). We have multiple ongoing projects (think different cases in different courts in different countries).

The thing is, the 800K pages of docs have not been fully reviewed (at this point, maybe 50%). So, we decide on work product (Monday; person 1 will do x by Friday) but by Tuesday afternoon, we've inevitably uncovered some additional documentation.

Too often, this documentation changes the whole story, changes the angle we need to come at it, changes the relationships. By Tuesday afternoon, the various legal teams (who do little investigating) request various work products in relation to this new find. My investigator/work product champion takes off on it, with a full heart, and (you guessed it) before it's done (all too often) we have even more information that changes things or causes a redirect. It's insanity.

We're processing, at times, 2-3K pages/day. So you can see how even a few bombshells in there cause havok like no tomorrow, and yet they are actually even less than 1% of total documents.

How are we supposed to handle this? Force through a week of finishing what we started? What if it's useless or wrong? Wait to produce until the investigation is done? More often than not, it's following one particular thread that itself leads to new revelations, AND we have statutes of limitations on filing this and that. Hire more staff? It would take months to have them gain enough traction to be useful, and guess who'd have to train them?

We tried kanban - the boards would get full of nonsense within a week or two. Having a high priority "fast lane" was a good idea.. until it wasn't. A burndown chart looks like a plateau, after you adjust for added tasks and how many remain unfinished... client (and product owner, really) wants someone to manage this crazy (yours truly), but doesn't really want to change their habits (which are mostly paper-based.. did I mention we're printing and manually reviewing all of these documents??)

Any and all advice and perspectives on this (especially with models or examples or actual "do this" suggestions) are so, so appreciated.

TL;DR: Management wants more control, more work product, more value per $.

Staff want to avoid the constant re-work, have an idea of what the overall strategy is, see their work-product actually getting shipped

I want to show that the above two are not mutually exclusive, and that there is a way for these needs to interface nicely, without a huge brake put on the workflow, wasted meetings, etc. I can see that these three wants are reasonable and rational, but there's a serious grind between them right now..

Answer 1

My first step would be to ask how you are doing Kanban?

Kanban is the go-to tool for rapidly changing requirements. The basic principle of "Have a board, have a WIP, prioritize daily", is incredibly simple. However, Kanban is really hard to do well. It's why I almost always start new teams with Scrum first, just so they can start to get the fundamentals of agile approaches.

One thing that sounds like is happening is a culling of the "backlog" or requirements. If things are changing when you discover something new, you need to ask if the existing backlog is still valid. For a normal software project I coach teams that anything over 6-12 months old should be removed. If it was important, it will be brought up again. For your project I'd say more than a month old is ripe for removal.

Second is clarity of your backlog, or user stories. You always need to be asking "Who is this for?" and "Why do they care?". We very quickly fall into the trap of saying "I need a drill!", when in reality what we need is a 1/2 hole in a piece of wood. A drill is just the most common way to get that hole.

I would advise you go back to Kanban as a base. Keep in mind the rigorous culling of the backlog and clarity of the backlog When you encouter a problem, do a "Five Why" analysis of the problem and always have your user in the forefront of your mind.

Answer 2

I think the simple statement of your problem is that to plan you need to at least be able to count the number of things you need to do. However you have no base number right now besides the 800K & 50%.

I also think you may be trying to apply project management to what sounds like process management. Maybe it's a little of both. I'm guessing.

If you need more people whoever is in charge is going to ask how many and you have no idea. Totally understandable, but, you need to be able to ask for something in a rationale way.

Tools: The old stand by tools like the "parking lot", or the issues list come to mind. Google spread sheets is a great tool for managing these with little investment in setting up something better. It's still a spreadsheet nightmare but collaboration works right away and it's free. You have to log issues, prioritize them, work the higher priorities. You'll need to have columns for cases, courts, and so on so you can bucket things.

Option one guesstimate the base: Given the urgency you seem to be expressing I would go with this.

Right now perhaps you have some at least anecdotal idea of how many subsequent investigations occur when you review say a 100 page case file. Don't focus on that number being perfect. Think best, middle, worst. Usually teams end up with a worst plus, BTW. Go with it. So 200 cases, 50 are best, 75 are middle, 75 are worst. That should equate to person hours.

Option two - better estimate: Have at least one person plow on through the last 50% of the documents. Read pages, log issues, and keep going. That will give you a count of the, say, "tier one" issues. Your team can probably more easily estimate how many subsidiary issue from each type of those will emerge.

Go forward: Every time you get a new case, if that's what the deal is, it has to be triaged so you can assign an initial work load to it.

So in review: a.) Structure your issue / work tracking with a super simple tool b.) Estimate the work using a best, middle, worst case model & derive needed people from there c.) Determine if you need more people and how long that will take d.) Go forward triage everything new, add it to the work load, adjust labor, scheduling, other priorities from there.

That's my going in set of ideas given what you've told me. Sorry if that's a giant "duh".

Answer 3

Agile methodologies are designed to cope with changing business realities. Not as commonly stated changing requirements.

It's a subtle difference but one which it sounds to me is important in your case.

A waterfall approach would be to collect read all the documents (make a plan) before beginning work (implementing the plan).

The risk in business with that approach which agile addresses is that during the implementation or later stages of planning, something happens in the real world which invalidates the plan. Say a deal falls through, or a new market opens up, and hence the whole project fails.

Agile addresses this by doing small bits fast. But each bit delivers value because the state of the world is known at that time. You can clearly see if the bit of work is correct or not. If something changes later the work might lose value, but the pace of change is set by real world events. Events which can't be planned for.

In your situation though the changes happen at the pace at which you read and understand the documents. A known task that will be finished prior to the end of the project.

So a small bit of work delivers no value for you if it is wrong, you won't know if it is right until the end and potentially has NEGATIVE value!

For you, Agile is a high risk approach. Essentially gambling that more bits will luckily turn out right than the time you spend fixing the wrong ones.

I would suggest you read all the documentation first and then do the work.

Answer 4

This may not be pure agile recommendation. But, by going by your problem, here is what I would suggest for this totally dynamic environment.

1. In your entire documentation, have section number + sub-section numbers + sub-sub-section numbers.
2. when your legal & other team is analyzing particular section, mark product co-ownership as legal + whoever it is
3. Track your progress based on the section and provide your guesstimate based on those sections. When you do grooming, go by section number.
4. Request the product owner (whoever is changing the requirement) to highlight in each version what they have changed. Add that change to your next release and you will be able track using section numbers + sub-section numbers.
5. If your product owner can come with MVP (or) prioritization, I don't think you will have these many issues. But I doubt whether they would be able to do or not.
   • Your section / sub-section has reference to your entire product backlog.

Answer 5

I have the impression that you need more structure in your project. Structure it in:

• sub projects, e.g:

  • Development of Module A
  • Development of Module B
  • Development of Module C
  • ...

• project phases, e.g.

  • Concept Phase
  • Basic Layout
  • Detailed Layout
  • 1st Prototye
  • 2nd Prototye
  • ...
  • Production planning
  • Market introduction

• different prototypes

• milestones, eq.
  • Concept study finished
  • Layout complete
  • First Prototype produced
  • First Prototype running
  • ...
  • Start of Production

For each sub project you need to generate a project charter which clearly defines the targets and non-targets of this part.

Especially the first prototypes don't need to fullfill all requirements. You could define for example like:

Prototypes:

• A-Sample: Basic Features but not fullfilling performance targets
• B-Sample: Main performance targets achived, only basic legal requirements at standard conditions fullfilled, for new product
• C-Sample: Main legal requirements fullfilled at standard and non-standard conditions fullfilled
• D-Sample: Mandatory requirements fullfiled at standard + non-standard conditions + Durability and Reliability proven
• E-Sample: Design optimized for production

The benefit here is that for the first Samples you can work with a very limited number of basis requirements. These requirements should be rather robust an not change to much in time. You can get a running system, where you can learn more. If you can convince your sponsor that you are on the right track, you can increase your team for building the more mature prototypes.

But the most important step is first to generate such a structure and the development roadmap. This will be a significant planning effort. Communicate, discuss and align this plan with your team and the other stakeholders. It is critical that everybody knows what to expect at what time.

Edit 1

I have just seen that you have taged your question with 'agile'. My suggestion is just classical PM aproach. Maybe agile is simple not the correct tool for your demand. You could use agile elements in some of the workpakage, but I have doubts that can only rely on agile methodology for the full development path.

Edit 2

Some comments on the nature of requirements:

• With the load of material expect that there are confilicting requirements. Especiallay if you consider stakeholders demmand. For example: you cannot build a perfect car which fullfils the requirements of all car costumers. One costumer wants a Ferarri Spider, the other wants a Volkswagen Multivan. You will have to decide which requirements to follow.

• Don't expect that you can make the correct design from the beginning. That every line of code, every screw and every processor is choosen correctly from the beginning. Product development is often a iterative process, so you'll have to rework your design several times.

• Some requirements are rather robust. E.g. legal requirements. Some are more floating. Try to start with the robust requirements first.

• If you have the first prototypes this will influence the requirements of your stakeholders. Maybe a stakeholder has a Propblem A and therefore demands as an absolute must the solution X to be implemented. However when you you desing your product, you might come up with more elegant solution Y for Problem A, which the stakeholder was not thinking of. If the stakeholder sees Y, he might change his mind and X is no must anymore. Key is to understand to problems of the stakeholders and find solutions, instead to try to implement every feature they request.

Edit 3

Scanning of the material is ok for the first place. But I would not try to extract every requirement in the first run. I would try to get an idea what is roughly disucssed in the individual sections of your material.

I would start to scan a part of the paper and than decide, either:

• "In this chapter there seem to be the major challanges for my concept. I'll investigate and implement these solutions in an early phase / prototype (Which?)", OR

• "This seems to be not to challanging requirements. I can adapt my design to these requirements in a later phase."