Free, Easy and Powerful Tool – the CBAP 007 Scope-O-Matic!

Just in case any of my readers think I (yes, I am CBAP 007) am only good for political analysis, I offer a simple BA “tech” goodie (our tech is different from their tech – this one works with paper and pencil, in a pinch!).

If you have ever been in a project where scope keeps wandering, even after endless discussions, just use the 007 Scope-O-Matic to sort it out in your mind. Once this is done, it will be easier to sort it out with the stakeholders.

Don’t write me telling me that this is the project manager’s responsibility – the project manager doesn’t face confused stakeholders day after day. Sometimes the PM acts like another stakeholder, announcing scope as if no one else could understand or discuss it. Often it is not in fact understandable, usually because it is oversimplified, and discussion is not welcome.

The secret is in not oversimplifying the scope (“To do requirements for a new order entry system” is not clear at all) and putting good boundaries on the problem. It is not enough to say what is in scope – often what is in scope “implies” other issues, not made explicit, yet leading to multiple confusing meetings.

Now, with Scope-O-Matic, you can identify more detail in your scope, and you can identify what is out of scope, and what is ambiguous in scope, as well as what is in scope.

If you have never tried this, you are in for a treat. Even if those around you never do sort out the “true” scope, you will have a lens into the confusion, one that will help you keep your head, while all around are losing theirs.

Have fun, let me know what happens. Even five minutes with this tool will teach you things that you know but hadn’t articulated – it is a great “gap” analyzer – do it for your project today!

Keep the discussion coming, here is your free tool!

IN and OUT of SCOPE, with “Possible Ambiguities”

IN SCOPE ??? OUT of SCOPE
Build a Prototype system Creation of a Prototyping Demo Environment? Creating an application environment.
Creation of a Prototype covering Order Taking, Picking and Shipping Electronic orders or just phone orders? Faxes? None of the marketing that leads to a customer making an order
Elicitation of user interface and functional requirements using prototype Capture or dispose of business rules discovered during elicitation? Elicitation of software, security, reliability or any other non-functional requirements
Documentation of functional Requirements and user access privileges Are user access privileges a part of security requirements? User or programming guides, response time requirements, system uptime, system scalability, etc.
Screen shots (in documentation) The screens have over 15,762 permutations, if you count menu views – how many screen shots? Functioning code of any kind
Process (functional) requirements (use case model & text) Level of detail? Traditional FRD non-documentation
Assumptions made by requirements team How to bridge critical “unspeakable” assumptions? Assumptions that are “unspeakable” yet critical
THE REST IS UP TO YOU

Have fun!


Don’t forget to leave your comments below

Marcos Ferrer, CBAP has over 20 years experience in the practice of business analysis and the application of Information Technology for process improvement. Following graduation in 1983 from the University of Chicago, Mr. Ferrer joined IBM in Chicago, where he worked on requirements and systems implementations in diverse industries. His recent projects include working requirements for the Veteran’s Administration, introducing BA practices at the Washington Suburban Sanitary Commission, and creating bowling industry models for NRG Bowl LLC. In November 2006, Marcos Ferrer is one of the first CBAPs certified by the IIBA. He has served as an elected member of the DC-Metro chapter of the IIBA, most recently as President, and assisted in the writing of the BOK 2.0 test.

© Copyright 2010 Marcos Ferrer