While waiting at a gate for the next available airplane at an airport, I met a fellow business traveler. We started talking about business and what we did for a living. He was a COO (Chief Operations Officer). So I asked about their planning process, what it means to be strategic and the common challenges he had witnessed. He opened up like a child that couldn’t wait to be heard. The conversation lead to eight common mistakes made in strategic planning.
I am constantly amazed at the generally limited use of images, diagrams, and models in documents created by those who perform business analysis.
In our profession there is a lot of discussion about what makes a business analyst a senior business analyst. To help better delineate between the levels of BAs the IIBA® has recently released a business analysis competency model which includes five levels of business analysts.
There will always be a debate about certifications and whether organizations should support them. Some feel they are an essential and growing part of professional life. Others feel a credential does not make practitioners a better business analyst, Agilist, or project manager. Both sides have a point, and the debate will continue.
Organizations are looking to fill the upper management positions that lead to the executive level to groom the leaders of tomorrow.
I’m going old school in a new way...Paper.
Paper is an application for iOS that is distributed by Fifty Three. I know a lot of individuals will comment that Paper doesn’t “do” enough, but what it does do is simple, elegant and, most of all, useful to a business analyst with a creative bent.
Some time ago I wrote a blog about the five terms in the planning process that every business leader and professional should know. It was part of filling in the strategic blank and getting to know the strategic planning process. With the word strategic, and by adding the word analysis, planning, leadership, management and implementation you get the perfect adjective-adverb combination. The terms are defined in my other article (5 Terms in the Planning Process).
There is a lot of talk among business analysts nowadays about something called an agile business analyst. This appellation is generally applied to business analysts who work in an agile software development environment. This is a topic of discussion among business analysts throughout the industry. Courses are being written and delivered about how to be an “agile business analyst.” There is a discussion group on LinkedIn, with the title “Agile Business Analyst”. One thread on that discussion group was started by Leslie Monday, August 29, 2011, titled “What Is An Agile Business Analyst” and it is still going strong. There are at least a dozen other threads in other business analysis oriented discussion groups on LinkedIn, attempting to answer the same question, and I’m sure there are similar discussions being carried on in other communities around the Internet, and most likely in local IIBA and other business analyst organization meetings.
We’re in Orlando for a working session as part of the Core Team building BABOK V3 and over dinner this evening we got to discussing the relationship between user stories and use cases (it wasn't the only thing we discussed, we are also a social group ;-)).
We noted with concern that there have been a number of recent discussions (client, articles, blogs and general industry) of using both User Stories and Use Cases at the same time in Agile projects. This seems to us (with general agreement around the table) to be both a waste of effort and actively against the Agile philosophy of doing the simplest thing that will work and deferring the detail until just ahead of when the component of the product will be built.
We would like to outline the basic differences, considerations and risks of using this approach. Even it is seems to be a trending topic, we would like to fill the gap in addressing beyond the trend and move towards the practically and risks of using Use Cases on Agile projects.
Is your project’s red-yellow-green status for requirements based on percentage complete of the requirements document?
Statistics show that the real figures regarding project success are not at all encouraging. Only 30% of projects are considered successful; the others are challenged oroutright failures.