Agreed! I've found this is the kind of habit that needs drilling into people: documenting things you're explicitly *not* going to do can feel awkward, I think - especially to juniors, but it's never been the case that having such a record was a bad idea!
I eventually settled on the framing of these things as Decisions - which I think helps both capture the decision at a point in time, and encourages written justification. We hadn't formalised the use of ADRs when I was doing consultancy work - instead we just maintained a bunch of tables documenting "out of scope" stuff, assumptions and known constraints, which was arguably OK, but wasn't great for tracking reasoning or impact of those decisions, and was easy to over-populate since it's very simple to list all of the millions of things you're not going to do - much harder to stick to what's actually relevant, the when and the why!
If I could go back in time and use a more explicit ADR log to document the *decision* to omit or exclude something, I absolutely would.
Yes, a shared decision register is a good tool during the development, set up to capture who, when, why, risks and issues.
I always have an exclusion section in contract, which other people think of as unnecessary, plus an exclusion section in detailed specifications.
It might be as simple as no hardware, no third party software, no interfaces, no help center support. Just document it, so there's no ambiguity. And state if exclusions are added to scope, a price and project plan are subject to negotiation.
No ambiguity.
As you did, documents every iteration of the development, with every tested and validated function, saves a lot of disputes, as well as being an invaluable dictionary for future enhancements, or the basis for training materials.
Along with process diagrams. I in this case, a process flow diagram for wayward goods would have had a line going to a sude box to show that it would be a manual process, not a process forming part of the software.
Great lessons Tom. It's a tall order for 3rd party analysts to thoroughly understand complex business processes and interactions in limited time.
Two from me...
4. Never assume anything...
5. Optimal use of new automation seldom implies a straight transfer and overlay of manual operating procedures...
(6. More of a fault of mine than a lesson, if tha wants ow't doin' right, do it thi'sen)
Cheers Paul! Very relevant nuggets of wisdom there too - especially about assumptions!
Always document exclusions. Always.
Agreed! I've found this is the kind of habit that needs drilling into people: documenting things you're explicitly *not* going to do can feel awkward, I think - especially to juniors, but it's never been the case that having such a record was a bad idea!
I eventually settled on the framing of these things as Decisions - which I think helps both capture the decision at a point in time, and encourages written justification. We hadn't formalised the use of ADRs when I was doing consultancy work - instead we just maintained a bunch of tables documenting "out of scope" stuff, assumptions and known constraints, which was arguably OK, but wasn't great for tracking reasoning or impact of those decisions, and was easy to over-populate since it's very simple to list all of the millions of things you're not going to do - much harder to stick to what's actually relevant, the when and the why!
If I could go back in time and use a more explicit ADR log to document the *decision* to omit or exclude something, I absolutely would.
Yes, a shared decision register is a good tool during the development, set up to capture who, when, why, risks and issues.
I always have an exclusion section in contract, which other people think of as unnecessary, plus an exclusion section in detailed specifications.
It might be as simple as no hardware, no third party software, no interfaces, no help center support. Just document it, so there's no ambiguity. And state if exclusions are added to scope, a price and project plan are subject to negotiation.
No ambiguity.
As you did, documents every iteration of the development, with every tested and validated function, saves a lot of disputes, as well as being an invaluable dictionary for future enhancements, or the basis for training materials.
Along with process diagrams. I in this case, a process flow diagram for wayward goods would have had a line going to a sude box to show that it would be a manual process, not a process forming part of the software.