Please take some time to read Fireproof Your Job.  The author, Donna Rosato, covers 6 strategies to help you overcome being one of the many impacted by the historical layoffs.  She also includes a short self assessment so you can see how vulnerable you are.

Please share your stories on how you implement or plan on implementing some of these strategies. 

FICTION: Agile means we don't need to do any documentation.

People that advocate this type of Agile Development are taking us back 10 – 20 years when the customers talked directly to the developers. It didn't work then hence the advent of the Business Analysis profession, so I am not sure why people think it will work now. There is still documentation, it is just a matter of focusing on value-added documentation rather than documenting laundry lists of must haves and shall haves.

FICTION: Agile means we don't need a Business Analyst?

The role of the Business Analyst is even more critical on Agile Development projects because the need for upfront analysis and continued management of the requirements is an absolute necessity. Agile Development projects require rigorous planning in the beginning so once you get into the iterations of design, development, and test, the team is simply executing against the plan. In addition, the Business Analyst has to be ever vigilant in managing scope and new requirements for each iteration or release. It is important the BA continues to do analysis and determine the feasibility of the requirements as well as document requirements as the evolution of the development cycle continues.

FACT: Business Analysts' need to be more adept at deciding what artifacts to use for different projects.

This is absolutely true. Gone are the days of 400 page requirement specifications (I wish I was exaggerating). Business Analysts' need to have the ability to assess a project and decide what artifacts will add value for that project. In this way, the BA will become more agile by default and will only use documentation techniques that help the project team deliver results.  

FICTION: The Agile Development Methodology will solve all our problems.

As with every methodology there are pros and cons to utilizing this approach.

At a lunch and learn titled “How do BAs show their value in a tough economy” I was encouraged to hear that all of the BAs at the table feel confident that their organizations understand the value of the BA role and don’t anticipate any layoffs. Apparently the BA role is quickly establishing itself as a key role that cannot be sacrificed!

See the conference web site for more highlights and the dates of future conferences: 

http://www.iirusa.com

Please take 15 minutes to take the new IIBA BA role delineation task survey. You do not need to be an IIBA member to take the survey.  Your responses will influence the BABOK V2.00 new exam questions and knowledge area question percentages. Let your voice be heard. For more information refer to this blog http://blog.theiiba.org/2008/11/babok-version-2-task-survey-your.html

For the survey, visit http://www.surveymonkey.com/s.aspx?sm=lukLKiuUOHaC5LQ13WcB3w_3d_3d  

The deadline for survey completion is December 17, 2008. 

If you do not currently receive the magazine you can subscribe by clicking here.  It's free!

Day 3 - Tuesday October 28, 2008 

Ronald Ross gave a keynote "From Here to Agility" today.  He began by reminding the audience that BPM (Business Process Management) continues to be very important when businesses want to re-engineer processes for more efficiency and value, but that it is really decisioning that gives each business their competitive edge. When he discussed decisioning he is really talking about a superset of business rules – those rules that are really strategic and rules that need to change often.

This comment seemed to be echoed by many presentations during the day. Most of the presenters when discussing business rules were referring how companies make decisions, the process they use to decide, the criteria used and how fast they can make decisions really gives the company the most edge. Processes are more static. As we teach about essential processes (what are the essential activities that need to be performed irrespective of how these activities will be enabled by any technology): the essential steps of a process will not change – how we implement them will change. He takes that even further to say that even processes that are implemented do not change that often except for the decisions we make during those processes. Those decisions are much more dynamic and change frequently as the landscape changes based on the economy, competitors, new customers, and the types of products and services sold. What he and many in the conference echoed is that anything that changes often like decisions need to be pulled out of the process into a rule. Every body knows in large businesses that it often takes IT several months to incorporate changes into a system. With today's rules-based engines (RBEs) a business person or any qualified product specialist like the business analyst can author, test, and implement a decision in a few days instead of months. This allows companies to be more agile.

My takeaway was that analysts need to consider with each requirement they capture if the content will change often over time. If it may, then it probably needs to be pulled out into a rule repository, segregated from the process model or even the data model and later put into a Rules engine (if it will be automated) where it can be managed and changed much faster.

Day 2 – Pre Conference Workshop

I got a chance to meet Scott Ambler, another thought leader who spoke about agile development. He is a prolific writer and practice leader of iterative and agile development. His teaching technique is to make controversial statements to incite you to think. It worked on me. I got worked up about a couple of his comments. I was motivated to speak up several times about the role of a BA and how it aligns well with the principles he discussed. I am still not sure whether he appreciates the BA role.

He is quite vocal that development does not need business analysts as a bottle neck between the developer and the business stakeholders. He maintains a go-between between adults is not necessary and can deter efficient and effective development. Believe it or not, most points that Mr. Ambler made are again the same principles we teach our business analysts. He reinforced the fact that to be successful in agile you need to know multiple techniques, be skilled to wear multiple hats, model and document only what is necessary and useful, and plan before you start working. He just never admitted that he knew BAs follow these same principles. Luckily the principles of agile development are not really new and have tested long before the "agile" name was coined. BAs can be a great asset to an agile project. I attended other sessions but these two pre-conference presentations were highlights for me and kept me thinking what a great time it is to be a business analyst! BAs rule at the conference!

Day 1 - Pre Conference workshop – Sunday 10/26/08

I was thrilled to attend a Business Rules seminar by Ronald Ross who is often called the "father of business rules". I brought along his book Principles of the Business Rule Approach and he graciously signed it for me. Mr. Ross made a great case why we need to document and manage business rules independently of processes and program logic. He reminded us that rules have nothing to do with hardware or software technology and are only concerned with describing criteria for business decisions, business terminology and business facts. 

The best question a BA can ask the business stakeholder is why do we have this rule and how does it support the business strategy and objectives? The other main thing is to ensure that everyone is using the same definitions for business terms. He calls these rules facts. He made the distinction that business rules should be specified by business people, not IT. He showed us a fact model which looked surprisingly similar to an ERD. But not the same he declared. He also clarified the difference between rules (which represent decisions and are not procedural) and processes (they transform and are procedural). He was adamant that rules should not be included in processes. In documenting process workflows Mr. Ross never includes any diamond symbols. Diamonds represent decisions which need to be documented as business rule statements. He stressed rule independence from program logic is needed so that the business can manage their rules directly without getting IT involved and the business maintains control and establishes traceability. The great news is that Mr. Ross's seminar was aligned with the principles we teach to our business analysts.

Business analysis involves very complex and sophisticated thinking patterns and advanced communication. A successful Business Analyst (BA) is the rare individual who can combine technical knowledge, business acumen, analytical skills and communication skills while being able to see problems from both a strategic and detailed perspective. Excellent BAs bring value to their organizations by understanding true business opportunities, making realistic recommendations, and facilitating the successful implementation of these solutions. Seven Steps to Mastering Business Analysis gives you the areas to focus on to develop your professional value.

Here is what Russ Peña, vice president & senior business analyst of SunTrust Banks, Inc. has to say about the book: "Seven Steps to Mastering Business Analysis is a definite ‘must read' for every Business Analyst. The topics, both practical and concrete, will provide indisputable value to your career development and to your projects."

Go ahead and pre-order your copy today!

The fours secrets are

1. Be good to your end user
2. Go beyond the walls of IT and learn the business
3. Understand the organization's structure and goals
4. Build trust with your boss

Don't you agree those are all qualities excellent BAs possess?   This quote from the article sums it up for me. '"People outside of IT won't necessarily understand tech speak, so you need to present information in a manner so they understand technology and what it provides to the company," says John Murphy, CIO of Hard Rock Hotel & Casino in Biloxi, Miss. Murphy's ability to do so has helped him in the executive suite with other C-level colleagues. "I've been able to translate technical information to them in the manner they can understand and assimilate and in a way that shows the benefits to the big picture," he says. '

I have been saying for awhile that the next generation of CIOs will be coming from the BA ranks.  So keep it up and be a star in your organization.  Soar all the way up to the C-level!!!