Blog Archives

SIPOC diagrams

SIPOC Picture

I find SIPOC diagrams really useful in the early stages of a project. They are a great way to capture a lot of information in a concise way and provide an “at a glance” view of the scope, the stakeholders

Posted in Investigating, Requirements, Tools & Techniques

Law of the Instrument

Give a small boy a hammer, and he will find that everything he encounters needs pounding Experience is hugely valuable but getting set in your ways is a constant danger. It is important to remain flexible and open minded –

Posted in Principals, Requirements, Tools & Techniques

Start with the end in mind

Treasure Map

“Start with the end in mind” is my number one principle. To clearly visualise what the end goal should look like and work backwards. To work out all the steps that need to be taken, or need to be in

Posted in Principals

IT can’t fix broken processes

Broken Process

The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency. – Bill Gates IT

Posted in Investigating, Principals, Requirements Tagged with:

80/20 Rule : The Pareto Principal

Pareto Principal

The term 80/20 rule  is widely used now in all walks of life to describe relationships between “causes and effects” and “efforts and results”  but what is the rule ? and what are the uses and limitations in business analysis?

Posted in Principals Tagged with: , ,

Faster horse

Faster Horses

“If I had asked people what they wanted, they would have said faster horses.” ― Henry Ford A trap I have seen numerous times is building exactly what the users ask for! That’s because it can be difficult to separate

Posted in Principals, Requirements

Requirements versus Functional Design: What’s the Difference?

Functional Design

In a nutshell one is what you want, the other is what you’re getting ! Requirements describe what is needed, what the solution will need to achieve but not the how. Requirements must not describe a solution. Separating requirements and

Posted in Design, Requirements Tagged with: ,