Skip to main content

Author: Marcos Ferrer

B.A. Survival Guide. Part 3

Written by Marcos Ferrer on . Posted in Articles. 1 Comment on 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

B.A. Survival Guide Part 2

Written by Marcos Ferrer on . 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!

© 2009 Marcos Ferrer

BA Survival Guide. Part 1

Written by Marcos Ferrer on . Posted in Articles. 1 Comment on BA Survival Guide. Part 1

A project is in trouble. You have been volunteered to help clean it up. A million details are spinning out of control, generating constant debate. Political egos have intervened, to no good effect, as they understand the details even less than the stakeholders and the project team.

There is just enough confusion and frustration that you see an opportunity to influence the egos to “re-set” thinking along clearer lines and key priorities. But how do you know what clearer lines are? Do you just express YOUR opinion about the details, and imagine that your opinion will suddenly be persuasive? How do you back your opinion up? Why are you qualified to lead or influence?

One answer suggests that you are qualified, because as a BA, you know how to raise your point of view. You can rise above the trees, to see the forest, and the coastline, and the mountains, and the sinkholes. Let’s look at how BABOK offers one platform high enough and wide enough to survey the situation. It is time to RTFM (Read The Pretty Manual).

BABOK offers a key diagnostic tool in the form of two tables, displayed below:

basurvival1.png
basurvival2.png

The trick to diagnosing is to size the project using the project sizing grid, and then consider whether the Enterprise Architecture artifacts are up to snuff – a gap analysis. At this point you review the BABOK EA sections (we all remember reading, yes?), using them as a checklist – any activities that were not performed can be considered as a possible approach to reducing the project confusion.

On many projects, this is easy – Any EA of value is simply missing, and in its place is some executive “vision” document. This vision document is often not questioned for political reasons (yes, I am talking about YOU, YOU know who you are, discouraging examination of your “brilliance”), EVEN THOUGH less is known about the problem at “vision time” than will ever again be the case.

In cases like this, the solution to managing complexity may be to figure out enough EA to fill critical gaps and re-set priorities. Don’t fall for the trap of believing that this must delay the project by another year – ANY EA is better than none, and a parallel track team can be set up to generate the highest priority EA, if necessary.

In one organization, document management had been considered for over 20 years. Every committee, every project, got wrapped around the axle of complexity, legal issues, departmental egos (we don’t do that!), and side issues (document archive retention contracts, much more). In the process, some EA was created, but there was almost NO business process/architecture devoted to the “document” problem. One diagram was created, showing the “AS-IS”, where it could take weeks to get a document, and suddenly the committee came together, and the project is underway.

On other projects, it may be sufficient to “re-visit” the EA – perhaps the business case needs modification, after all, some unanticipated risk has emerged, there may be a key business process “AS-IS” or “TO-BE” that was not described properly, perhaps a feasibility “SWAT” team can resolve important technical issues.

In the event that EA is NOT the issue, it may simply be that complexity is – some problems are too big to solve, yet sometimes we must try. The solution here will require digging deeper into BABOK, and deeper into other best practices – stay tuned for BA Survival Guide. Part 2.

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

Have fun!

© 2009 Marcos Ferrer

B.A.gile!

Written by Marcos Ferrer on . Posted in Articles. 1 Comment on B.A.gile!

This is NOT another Agile Methodology posting.  I make no claims to any special agile expertise, nor am I interested in methodology wars.  I just want to say that fads are fads, and never substitute for analysis.  I completely understand the attraction to agile.  It is an excellent summary of what can work for some teams, on some projects.

It is my observation that all the named methodologies I have run into can map onto BABOK concepts, and the BABOK is a superset of them.   

Here is the manifesto itself for context (derived from the Agile organization’s own web site at www.agilemanifesto.org ):

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

———————————————————————————

And here is one analysis, based on general knowledge, personal experience and BABOK concepts:

  • BA Fundamentals (and hence the essential skills to perform Requirements Communication) have to be present before tools matter.  Tools can only support competent, effective behavior, not create it.  In a sense, all successful projects are “agile” – it is my observation that all successful projects are full of brilliant individuals who interact fast and freely.  This single factor seems to compensate for everything else – counterexamples are welcome, I don’t have any.
  • Software over documentation is already the most common approach in software development, so it is hard to understand why it matters to “Agile”.  Since 65% “failure” rates are already being achieved in software development, it must be items 1, 3 and 4 that really matter, if Agile is effective at all.
  • Substitute “Iteration of Requirements with Stakeholders” for “Customer Collaboration”, and substitute “waterfall requirements” for “contract”.   Contracts, at their worst, are an attempt to “lock in requirements” before they are understood, leading to excess change order profits for the contractor (when changes are allowed), or failed stakeholder acceptance (when they are not).  Waterfall requirements are best saved for “one shot” efforts like the moon program.
  • Over planning, and reluctance to adjust plans as requirements are “learned”, is clearly a cause of certain project failures – it is mostly a failure of intelligence (see item 1).  What is missing from this concept is the idea of Enterprise Analysis (especially risk analysis, stakeholder analysis, and cost benefit analysis) and the Requirements Planning that must follow from these.  Another way to put this is – IF the project is simple and low risk enough, Agile may be a fit (see BOK tables 3.0 and 4.0 in the Enterprise Analysis section, and see if you can spot which projects might use Agile.

SO, from analysis to opinion (if you have your own opinion, send it in, we will tally responses and report on same):

IN MY OPINION:  Agile process fits certain kinds of projects, but hardly most.  Here is my list – what is yours?

“Small potatoes” – low risk, decent to high payback systems that only have to satisfy a small number of users with homogeneous interests, have low visibility, or represent proven, successful increments to already successful systems (yes, maintenance and enhancement).

 “Feasibility” or “Proof of Concept” trials, which could clear the way for more investment in a larger project?

 “Research” projects, where almost all is unknown, budgets are huge, and the paybacks considered indispensable, if they can be achieved at all.  These are really rare; one example was the “skunkworks” team that developed the unique (and ultimately unsustainable) Blackbird spy plane.

“Invention” projects for systems that can succeed “virally” and evolve, that represent completely new behaviors ,or huge boosters to behaviors, that people crave, regardless of how poorly delivered (e.g., cell phone service, social networking, 45rpm records).

WHAT AGILE PROBABLY DOESN”T DO is Enterprise level projects, projects that must organize the efforts of many people.  I am sorry to say that I hold this opinion in spite of the fact that I helped lead just such a success – an Investigation Management system for over 1400 government users.  We succeeded by using all four principles in the Agile Manifesto, AND this only worked because we were an A-1, Agile Item 1 team.

My advice – get the smartest team you can that actually CARES about their work, and put them under tremendous pressure – they will cut to the bone, and will NOT skip any critical steps, and you can call it Agile if you want, but I call it B.A.gile!

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

Have fun!

The BAs are Coming! The BAs are Coming!

Written by Marcos Ferrer on . Posted in Articles.

BA Fire Alert!  How will the new Administration impact Business Analysis?  Please go to http://citizensbriefingbook.change.gov/ideas/viewIdea.apexp?id=087800000004t42&srPos=2&srKp=087 ASAP and vote!  There is a nationwide “brainstorming elicitation” being performed by the Obama transition team, and the idea in the link above is a BA clarion call!  This is your chance to be heard in an important new way, using a state of the art elicitation technique.

If you don’t like the idea you see, add your own, but PLEASE get involved – this is important.  It is a unique chance to lobby on a level playing field.  Tell your friends, your bosses, your professional colleagues, your government employee friends, spread the link by email, use your Linked In contacts, Facebook, the works!

The inspiration for the above initiative is that a different kind of Story from the Front has come to my attention. We are so consumed with our experience of BA (or its lack of practice in our immediate environment) that we don’t think about what this means for people’s lives.  Thinking about this is important; it keeps us in other people’s shoes, and is good practice in learning how to “say” things to be heard, supported, and gain consensus.

Check these samples out, and send me an email ([email protected]) letting me know which one(s) you relate to the most, and sharing YOUR story.

Story 1

“I certainly agree that business analysis has real value in the government sector. It may be interesting to note that I am currently engaged as a consultant in a Feasibility Study and Cost/Benefit Analysis for a state government project. I am proud of the techniques and skills that I, as a BA, can bring to the team performing the Feasibility Study and to the client who is fully committed to supporting the effort.  

“The business problem goes well beyond abstract notions of IT and process. It impacts thousands of children who are subject to abuse and neglect, foster and adoptive parents who take them under their care, case workers who become their advocates, and community organizations and private providers who deliver vital services.”

Story 2

“I recently was asked to join a government project for a federal government web service that was struggling with requirements.  With the support of another CBAP, we were able to help improve the requirements somewhat, but only with incredible resistance from the project management itself.  This resistance came in spite of the fact that CBAPs were hired specifically to satisfy the government that the requirements were being handled well.

“While the project will go on to “succeed”, there were cheap, powerful opportunities missed, all because project management had better ideas than stakeholders. I saw this as a direct “violation” of BA values, and did what I could to encourage stakeholder ideas. 

 “When you realize that the project would be a great benefit to this agency’s “clients”, it is a shame that these opportunities were missed. But I am confident that they will be  implemented in time – requirements get “paid now or paid later”, as always.

“As BA is increasingly better understood, I am guessing that this resistance will diminish.  The government clients were pleased enough with the CBAPs’ work, and felt they had been heard well when we were done.  The project management contract was not renewed, and one of the CBAPs was brought back to follow up with requirements on the development side.

“Like life, this was imperfect and messy, yet there is a positive trend in the outcome.  Clients ultimately love the integrity of the BA values and approach, and I love being a CBAP, and I love that the government “clients” in this case will get a better service from my contribution.”

Keep sending me your stories, and remember the people that we ultimately serve!

Thanks to my gentle readers for their frankness and willingness to share.

More shall be revealed.

Have fun!