B.A. Survival Guide. Part 3

This month we consider what to do (in some cases) when appropriately selected requirements practices and tools are misused.

Remember, we are assuming that the practices and tools are a good fit for the project, and that they are misunderstood or misused.  Here we go, starting with a BA productivity killer with more impact than many folks realize.

Project Document Deliverable Templates. These are required (and even useful checklists) on larger projects.

Problem:  Even though the template defines a deliverable, management insists on documenting requirements in the templates as they are being discovered and analyzed.  Because templates are “format heavy”, this slows the analysis. Requirements that may not survive analysis are documented along with others that may, and the need to “keep the template pretty” adds significant overhead to all the changes that result.  The overhead is increased even more if some aspect of analyzing or organizing the requirements (outlines, spreadsheets, speculative use case drafts, and attempts to reconcile conflicting or similar requirements) doesn’t “fit the template”.  This is often the primary cause of participant reluctance to allow requirements changes when they are still cost effective for the project because they don’t feel cost effective to the worker who has to do them, and it becomes difficult or impossible to focus on important issues, instead of losing time to “prettification”.

Solution:  Most analysis, especially early in the exploration, is best done with lists, outlines, spreadsheets and other text based lightly formatted tools.  Even use case models are best started as lists, and drawn after the list has been given some thought  As a BA, you must be prepared to produce analysis working documents as well as “formal deliverables”.  Do your best to “finalize” your analysis of the requirements in the format best suited to that process before fitting them to the deliverable.  If management insists, copy and paste your working “requirements” into the appropriate section of the template at the end of each day, and ask for tech writer help in formatting (not changing) them.  Remember – BAs are supposed to be good writers, and good writers are usually re-writers – just do it! 

Use Case Models. These are highly recommended and incredibly useful. What could go wrong?

Problem:  High business value use cases (sometimes called primary – example: I can use an ATM, and when I’m done I have cash in hand) are NOT distinguished from administrative, supporting, or lower business value use cases (sometimes called secondary – example:  I can change my address online, and when I’m done my address is changed). 

This leads to a tendency by the team to over-focus on completing all use cases (or worse, the simpler use cases, which seem easier to complete), at the expense of REALLY working the high value cases until they are completely understood by all stakeholders.  At some point the highest value cases ARE understood (hopefully not months after project delivery), and typically require extensive rework of the “overworked” supporting cast of other requirements.   

Solution:  Do remember that the FIRST use cases in any use case model should be high value use cases, and keep this priority operating at all times.  The high value needs will inevitably drive changes to the lower level details; trust this process and let it work. 

Question:  As an exercise, which of the following business outcomes (potential use case outcomes) could be high value, primary requirements drivers?

A) Customer receives on line order confirmation.
B) Customer sets up account profile.
C) Sales Manager gets sales trend report.
D) Salesperson records monthly sales figures.
E) Customer gives credit card for payment.
F) Customer receives timely refund.

Wait now, don’t peek:……………………………..

• .
•  
• .
•  

Answer:  A, C, F

More shall be revealed. Keep the feedback coming to [email protected].

Have fun!

© 2009 Marcos Ferrer