Home
What's New
Use Case Basics 101
UC Concepts 201
UC Concepts 301
Simulation
BA SMEs Waste $$$
Business Processes
Software Testing
Outsourcing Risk
Founder's Profile
Testimonials
Press Releases
Our Services
Contact Us
 

Process Simulation Steps

How Do Steps in a Simulation Process Approach Vary?

Using a process simulation for requirements discovery and documentation will necessarily change the steps to deliver the highest quality. The process will be more iterative.

A primary goal is to create conversations early in the process so that undocumented assumptions or missed requirements do not cause rework later, when it is more expensive. When people involved are clear on what they are agreeing to they naturally build consensus and buy in to the solution.

When participants agree, expectations are realistic. When expectations are realistic, customer satisfaction goes up.

Side-By-Side Comparison

The process in the Today without Simulation column in the graphic below represents a typical requirements process.

The steps in the Tomorrow with Simulation column is a generic simulation process. Either a business process or requirements for software may be the system documented. The Building Requirements Consensus™ Approach works well with both.

Process simulation is more iterative, builds clarity & consensus, and buy in up front than static text based requirements.

Steps Without Simulation

In the steps without simulation, the first opportunity that stakeholders have to experience what the solution looks like and how it behaves is at Step 5. This could be months later after significant work is already done. Changes are expensive and time-consuming.

It is common that original functionality is not delivered as a result and costs can substantially exceed original estimates. Sometimes, missed requirements end up becoming a "new" project - effectively covering up problems with the original project.

Steps With Simulation

The steps with simulation are more iterative. A wider audience of people with different responsibilities can effectively have their voices heard early in the process at Step 3.

The simulation is refined until people are clear on what the solution is and they reach consensus. Then development begins.

The simulation itself is delivered as part of the requirements. This becomes even more important in offshore outsourcing situations. A simulation is much less ambiguous than words. You can say "Make it work like this."

A Big Difference Is Time

When using a simulation process, the total time of the project is shortened. There is a greater chance that the right application will be developed and delivered the first time.

When a project is delivered right the first time, capacity for other projects is increased. The number of projects that can be delivered in the same time period go up using the same number of people.

Follow this link to see an example where a process simulation itself solved a two year old business problem. How much did this delay cost in direct expenses on the team? How much opportunity cost was there because cross selling of a highly profitable service was delayed for two years?

From Process Simulation to Building Requirements Consensus Home


footer for process simulation page