marcosMarcos 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.
AddThis Social Bookmark Button

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

Comments (2)Add Comment
...
written by Line Karkov, February 18, 2010
This seems to be very easy and useful. However, in my own experience defining scope is also to a great extent about agreeing on definitions on terms and concepts. I work in an internal development department where we support 6 different brands. Usually we work with group wide solutions but I have found out that not all stakeholders (for example representatives for the different brands) share our understanding of this concept, and this understanding is very important for the understanding of the scope. So I would probably add a fourth column called "Definition of terms" when using this tool.
...
written by Marcos Ferrer, June 23, 2010
Defining terms is an excellent suggestion - one of the reasons for sharing this tool is that is forces folk to discuss what everything means - by adding the "ambiguous" column, the need for definition becomes even more clear. One technique I use is to code everything that is defined well in black, everything not yet defined in red, AND the explicit "glossary" would improve the use of the Scope - O - Matic.

thanks for your comment - we shall overcome!


Write comment
We love to see comments! However, please do not market or sell any products. Your comment will be removed immediately!
smaller | bigger

busy