Mitigating the waterfall effect.Read More
You’ve poured your heart and soul into drafting the perfect requirements specification. You’ve checked, doubled checked, and triple checked every syllable of the document for clarity, spelling, testability. You have full traceability to every business requirement. You’ve been extra, extra careful not to tread in the domain of design. Your spec is rock solid.
So, why, after 5 review sessions with project stakeholders and document consumers, are you still making edits?Read More
- Tweets of the Week – 20180713
- The Real Value of Visuals in Solution Delivery – A Reprise
- Hippocrates on Clarity of Language
- The Book, The Movie, and the Business Document
- Interview with Ryland Leyton, author of “The Agile Business Analyst”
- John Dewey on Starting with a Problem to be Solved
- Business analyst, these are the reasons your project will succeed
- Four Critical Components of a Meeting Invitation
- Benjamin L. Kovitz on Requirements
- Business Analysts and Grammar Police
- Visionary Leadership and You
- Alistair Cockburn – Agile is an Attitude
- Business Analysis Success is . . .
- Harold Evans on Creating Understanding
- The “Obviousness” Danger that Kills Projects
- Jabian Journal and Visual Communication
- Distinguishing between Business Rules and Software Requirements
- Roughly Right, or Precisely Wrong?
- 6 Guidelines for Building a Reputation with Your New Employer
- Why Stakeholders Don’t Tell You Everything