B.A. Survival Guide Part 2

Written by Marcos Ferrer on April 7, 2009. Posted in Articles.

Last month we examined the fact that most projects get in trouble because they have not done their EA homework, as suggested by the BOK 1.6 project risk and sizing tables. These are being dropped from BABOK 2.0, so hang on to them!

Now we consider troubled projects where the EA is actually sufficient. What to do? It depends on the nature of the trouble.

Here is a list of the most common types of trouble in my experience:

Complexity The project is so large, with so many stakeholders and participants, that effective communication is simply impossible (see figure 1 – each blue dot is a participant, the red lines are “communication potentials” or relationships). TO FIX THIS this, remember that inside every overly complex, failing project are multiple small, successful projects, yearning to be free. Break it up into teams of six or fewer, or call it quits or save the money before it is gone.
Cultural Attitude Whether the problem is control freak management, siloed stakeholder politicking, a lack of executive involvement, or users disinterested in change, the result is the same – an elimination of trust and transparency that defeats true understanding of root causes and solution opportunities (and tends to prevent EA). TO FIX THIS, consider establishing a BA Center of Excellence – over time this can open things up, AND it is not a short fix. IF you can’t just find a better environment, or are committed to staying with your current project, then you must operate as a spy – collecting intelligence, turning enemies into allies, and persistently providing the best BA you can, even if not fully embraced. Good luck!
Inappropriate Selection of Requirements Practices and Tools. TO FIX THIS, identify a point of confusion or contention on the team, and then SHOW, DON’T TELL, an example of a better tool that you have used to clarify the point. If it is a better tool, the confusion may reduce, and folks will be interested in trying more new ideas. Example: Prototyping is being used to elicit business requirements from high level executives. Because the executives are wrestling with large policy questions, every issue they identify in the prototype leads to HUGE changes in design and emphasis, and this is happening repeatedly. Every week is a NEW prototype, extremely different from the old, and the executive discussion enters NEW territory, with even more fundamental policy questions. The policy debates are not converging, but continue to not get resolved. TO FIX THIS, start using USER STORIES and MEETING MINUTES. The user stories are much cheaper and quicker to modify, and present “policy matters” much more clearly (e.g., rules for authorized users are explained, not merely presented as a pair of log in fields on a screen). Meeting minutes are the real key, as policy debates can be tracked as action items, and all ideas related to a given policy can be grouped in ONE PLACE, instead of being distributed across the many screens of a prototype.
Mis-use of Appropriately Selected Requirements Practices and Tools. TO FIX THIS, you must wait for another month; we are out of time and room. While you are waiting, send me the WORST mis-use of methodology/practices ever inflicted on you!

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

Have fun!