The reason we write is so that someone can read it in the future. Duh. When we’re writing requirements documents, or documenting processes, how often do we stop and think about who will be reading our documents? We need to make sure our writing will be easy to read for our audience.
Agile / Business Analysis / Process Improvement / Project Management / Requirements gathering
Posted on:
Burndown Bullied Into Business Analysis
Burndown is a technique used in Scrum projects for tracking the progress within or across sprints. It is an exciting way to track how a team is progressing against a deadline – and we can apply it to any form of project-status. In this article, we will apply it to […]
Business Analysis / Requirements / Requirements gathering
Posted on:
Estimating the Effort of Documenting an As-Is Process
Estimating the gathering of requirements is hard. Not as hard as scheduling innovation, but easier than estimating implementation effort. One step in gathering requirements is often the documentation of the “as-is” process – how things exist today. We provide a framework for building those estimates – making the job a little bit easier.
Business Process Modeling
Posted on:
Free BPMN Stencils for Visio 2003 and Visio 2002
In support of our series of BPMN Tutorial posts, we’ve created a series of Visio 2003 stencils (*.vss) and a template (BPMN_Template.vst) of BPMN symbols. Download this free resource today courtesy of Tyner Blain!
Business Process Modeling / Requirements / Requirements gathering
Posted on:
Cost Reduction Potential
All process improvements are not created equal. How should we select which processes (or process steps) to improve? How do we approach this for a really large migration project? Start with understanding the potential for improvement and then narrow it down from there.
Business Process Modeling
Posted on:
Process 2006 – Day 1 by Sandy Kemsley
Sandy, of Column 2 fame, is blogging the Process 2006 convention “live” as it goes. Subscribe to her blog to stay on top of things. For now, here are the articles she’s posted from day 1.
Business Process Modeling
Posted on:
BPMN Deadlock
One danger of using a precise language like BPMN to describe business processes is that you can precisely get yourself into trouble. Deadlock (in BPMN) is a condition used to describe a process that can’t be completed. By designing (or describing) the wrong business process, you can create a process that never finishes.
Business Process Modeling / Requirements
Posted on:
Before And After – A Rule For Improving Processes
Nils proposes his rule of three boxes as a consideration when developing software or software features to improve business processes. In short, make sure that you can actually execute the new process. It isn’t enough to create a good “replacement process” – you have to be able to transition to the new process and then back out of it. The new process is plugged into a business ecosystem, and it must coexist with the existing processes.
Business Process Modeling
Posted on:
BPMN Compensation Event Correction
One of our readers (thank you!) pointed out that another blogger was critiqueing one of our earlier business process modeling notation (BPMN) diagrams. Turns out we made a couple mistakes. Here’s a more detailed look at the compensation end event.