8

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..

  • 1
    The first thing to ask yourself is: is agile the right fit for what we're doing? If your requirements and tasks change daily since you're constantly uncovering new information, then you may need a different approach. "Force through a week and finish what we started": don't do that. PM methodologies are there to help you, and you take and use what works for you. They aren't rule books that dictate how you work. Agile says you should plan some work up front (user stories). If you're not sure your user stories actually need to be completed, why are you going with agile? – dKen Apr 8 '17 at 3:47
  • 3
    @dKen, Do you maybe mean "Is Scrum the right fit"? Agile is a set of four values and twelve principles that are behind a lot of different ways to do things. A week iteration is a part of Scrum or XP, not specifically agile. – Joel Bancroft-Connors Apr 8 '17 at 4:23
  • 1
    @JoelBancroft-Connors Apologies, you're right, thanks for the reminder; this is why I love this site. I'm going to go away and read my agile books again! – dKen Apr 8 '17 at 4:59
  • 1
    If you're 50% into the documentation, you can live through the current chaos using one-week iterations, changing the task board daily, and forgetting about burndown charts until the other 50% is processed and some stability may be expected. Agile is perfect for situations like this. – Apalala Apr 9 '17 at 0:16
  • 2
    @Gryph If people understand what's going on, there should be no frustration and no burnout. Whatever gets produced will serve as feedback for this state, and as learning for next stages. Of course, there should be no pressure for stable functionality while the chaos lasts. As to the cost, it is the cost of doing business under the particular circumstances. The analysis of the documentation is only 50% away from enabling a less chaotic workflow. – Apalala Apr 10 '17 at 16:34
4

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.

  • Yes, user stories might be key here. I had brought the idea up before, but I think from a perspective of group-understanding, it might help significantly. So from a daily chaos perspective, you'd say just backlog then cull based on new understanding (If I understand correctly). Is there any way to do this strategy, but in reverse (sorry, that might require a read through twice.. yikes.) Is there any (effective) way to triage work and cull tasks that are likely to have less impact, when "everything is important, everything has to get done" – Gryph Apr 10 '17 at 13:05
  • I should add the ol "when everything is important, nothing is important" seems to have little effect here. I feel it need to be more a tool/solution/process. That I might be able to sell. – Gryph Apr 10 '17 at 13:05
  • @Gryph the visualization should help people understand the size of the backlog and help them realize that there's only so much that can get done at once. Force a priority. It's reasonable to refuse to do anything until the person who can choose a priority item has done so. Stand firm. Don't let them play that "everything is priority zero" crap. That's them shirking their responsibility onto you. – RubberDuck Apr 13 '17 at 23:33
4

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".

  • It's no "duh"! and thanks for your thoughtful support. I did consider most of this, but at some point, you wonder if you're sane and whether or not you're adding any value. The big hold here is that management wants more control, more value per $, more time spent making work product, but that "its a constantly moving target" is brought up more often than I'd like to admit, making those "wants" a lot more difficult to achieve. – Gryph Apr 10 '17 at 12:57
  • 2
    Perhaps your value add may be holding a hard line on the simple fact that every methodology, work model, tool, what have you involves prioritization. If I stand two stories, deliverables, issues, problems, tasks, whatever next to each other, unless they are 100% identical, one is more important than the other. – JackW327 Apr 10 '17 at 16:25
2

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.

  • Yes, in an ideal world I'd agree with you - I'd prefer we sprint to finish all of the documentation, then determine work product from there. Unfortunately, you'll note in my question that this isn't really an option; we have ongoing processes that can't stop now to wait on the investigative portion. So what I need is a model or a tool for regaining some control, or at least facilitating decision making as a group. Kanban would work if it had enough buy-in, but management (and myself included), put the rapid changes down to making it not responsive enough. – Gryph Apr 10 '17 at 12:55
1

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.
0

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."

  • 1
    Now, to be clear, this isn't 800K pages of requirements, it's processing, internalizing, collating and adding a legal framework to 800k pages of documents. Would you stand ith your answer on this basis? – Gryph Apr 12 '17 at 23:17
  • Yes. Is still have the impression, that you need more structure. You can invest 1 or 2 days (best when you have littel disturbance - weekend?) to try to get a rough structure of your development plan. Try to to structure your project according to the different categories. Don't try to plan everything in detail - you would get lost again in the information overload you have already, try to get the bigger bigger. Then check how such plan feels for you. If it feels ok, procced, if not you have invested only 1..2 days. (I'd be intrested to see a posting here, with your exerience after that) – BerndGit Apr 13 '17 at 14:00
  • Some comments to the nature of requirements added. – BerndGit Apr 13 '17 at 14:15
  • Edit: Paragraph about the number of requirments removed, since this is not the key message here. Another hint: Develop the first draft of the plan on your own. Then discuss it with your team. It will be happy to see an overall strategy beeing developed, and will have many valuable input based on the information which has been processed already. Later present the adopted plan to the management to get their input and agreement. Also management will be happy to get a clear overview on the plan. Keeping this sequence is important. – BerndGit Apr 15 '17 at 14:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.