Tag: Business Analysis

Agile Business Analysis in Flow: The Work of the Agile Analyst (Part 2)

Written by Ellen Gottesdiener on February 15, 2011. Posted in Articles.

In Part 1 of “Business Analysis in Flow – The Work of the Agile Analyst ,” I talked about the new skills and attitudes business analysts need to bring to agile development. When your organization adopts this value-centered approach, you need to have, as I wrote, “a tolerance for ambiguity along with a concurrent drive for specificity and closure.”

Now it’s time to talk specifics. What exactly do BAs do in agile development? How will your activities differ from those of traditional development? Let’s take a look at agile business analysis from the perspective of the activities that make up requirements development and management, comparing traditional with agile analysis.

Setting the stage: Requirements planning activities

To set the stage for requirements, the team strives to create a shared understanding of the product by all the stakeholders.

Traditional Analysis	Agile Analysis Adaptation
Attend project chartering sessions to define a vision, glossary, requirements risks, and product stakeholders.	Design, facilitate, or participate in product vision and roadmapping workshops. Help your customer understand which roles and themes to best deliver in each product release. Help your customer and team identify logical groupings of value-based requirements, and use these groupings to create a product roadmap showing incrementally delivered requirements over time. These requirements often take the form of minimally marketable features, stories, or epics (i.e., large stories that cross releases), use cases (high level only), events, or a combination.
Review and modify a list of tasks, time, and delivery dates in a work breakdown structure plan developed by the project manager.	Design and facilitate (or participate in) release and iteration planning workshops. Regularly prune the product backlog by collaborating with team members to generate a relative size estimate for backlog items. Conduct analysis “spikes” (short, timeboxed research stories) to elaborate on backlog items that need more analysis, researching requirements and their priorities.
Generate a SWAG (“S#*&-Wild-Ass-Guess”) estimate of time, effort, or cost for each requirement in the specification or user requirements document.	During iteration planning, together with the rest of the team, write down the needed tasks to deliver each user story, and estimate how many hours they will take. Share actual time usage information with your team so that the team can track progress via visual graphs (“information radars”) such as burndown, burn up, or cumulative flow diagrams.

Requirements elicitation activities

During requirements elicitation, the team identifies the sources of requirements and then discovers, derives, evokes, and elicits requirements from those sources.

Traditional Analysis	Agile Analysis Adaptation
Plan how to elicit requirements using a variety of techniques.	Use face-to-face, collaborative elicitation techniques (workshops, prototypes) as much as possible while avoiding techniques (interviews, surveys, documentation study) that require longer lapse times or interpretation.
Plan, design, and facilitate requirements workshops over weeks (or months).	Plan and facilitate short, informal requirements modeling sessions throughout each iteration. Plan and facilitate product vision and roadmapping workshops and release planning workshops. Teach your customer about supplemental analysis models so that they can question, participate, critique, review, and approve them (this should be done in traditional projects as well). Sketch out prototypes and identify user acceptance test data in real time, while a story is being designed, coded, and prepared for testing.

Requirements analysis activities

During analysis, the team seeks to understand and define requirements so that stakeholders can prioritize their needs and decide which requirements to build.

Traditional Analysis	Agile Analysis Adaptation
Define the scope up front by using a set of requirements models as the basis for detailed modeling.	Help your customer define the vision and the scope up front-at a high level only. Help your customer and team create lightweight models during product roadmapping and release planning. These models help customers carve out a value-based release schedule that balances business priority with architectural dependencies. Collaborate with architects and developers on design to ensure that requirements include the technical aspects of the product.
Develop analysis models for the entire set of requirements that are in scope.	Help your customer and team develop stories (user stories as well as stories that incorporate or separately define quality attributes). Help your customer and team develop and extend analysis models that support understanding backlog items selected for delivery in an iteration-if and when needed.
Ask the customer to prioritize requirements using a ranking scheme. If the customer is not available, do the ranking yourself.	Help your customer assign a business value and a ranking to each backlog item. Help your customer understand requirements dependencies that might warrant adjustments to backlog rankings. Question rankings based on goals or themes for upcoming release or iterations. Assist your customer and team to right-size high-priority backlog items that are too big to deliver in combination with other high-priority backlog items in the next iteration.

Requirements specification activities

Specification involves refining and organizing requirements into documentation (typically a software requirements specification). This includes the entire set of functional and nonfunctional requirements to be transformed into design, code, and tests.

Traditional Analysis

Agile Analysis Adaptation

Write a requirements specification.

Help your customer and team write stories (or if you’re acting as proxy customer, you write them).
Create doneness criteria for stories so that each becomes a well-defined, small piece of valuable software for delivery in the next (or current) iteration.
Create user acceptance tests or sample input and output data for each story.
Determine the form and format of documentation that is necessary and sufficient for requirements-related work-in-progress, handover, or product documentation.

Requirements validation activities

During validation, the team assesses whether the product satisfies user needs and conforms to the requirements.

Traditional Analysis	Agile Analysis Adaptation
Set up and run meetings to review and sign off on requirements documents, and help customers run acceptance tests after the entire product’s code has been created.	Meet with the customer and some team members to prune the backlog (once or twice each week). Participate in iteration demonstrations and listen to stakeholder feedback on the delivered requirements to learn the customer’s real needs and determine how to adapt the evolving product. Plan and facilitate, or participate in, iteration retrospectives, and learn from the customer how you can help deliver value faster.
Communicate with developers or testers (or respond to their e-mails and calls) to explain information in the requirements document; attend or run formal requirements review meetings.	Conduct just-in-time analysis modeling with customers and your team to validate the business value of each story and to ensure it will be delivered to the customer’s satisfaction. Participate in daily stand-ups. Sit with developers and testers as they are building code and tests to explain the story and its doneness criteria.
Help testers create user acceptance tests, or run those tests, after the entire product has been designed, coded, and unit/system/integration tested.	Define input data and expected results or specific user acceptance tests as part of defining doneness for each user story, iteration by iteration.

Requirements management activities

Requirements management involves monitoring the status of requirements and controlling changes to the requirements baseline (“a point-in-time view of the requirements that have been reviewed and agreed upon to serve as the basis for further development,” Gottesdiener 2005).

Traditional Analysis	Agile Analysis Adaptation
Establish the requirements baseline, document change control processes, and generate requirements trace matrices.	Help the customer and team establish a product backlog and define the smallest necessary requirements attributes for each backlog item. Help the customer and team define “just enough” requirements tracing needed to satisfy external regulatory body expectations. Help the team determine simple, meaningful requirements mapping and organizing (features to stories, events to stories, etc.). Define simple, unobtrusive ways to trace stories, with the aim of capturing metrics that will be useful for reuse and promoting development efficiencies.
Attend or schedule change control meetings.	Help the customer and team prune the product backlog continually (reprioritize items, break down stories, assign rankings, estimate size, and explore requirements dependencies that will impact architecture and therefore release planning). Help the customer maintain the product backlog items (on story cards on a wall, in a spreadsheet, or using an industrial strength agile requirements management tool)-or do this on behalf of the customer.

Learning: The heart of agile success

A mantra for agile teams is “inspect and adapt.” This means regularly checking on the delivered product and the processes used. Continuous improvement (called “kaizen” in lean approaches) is essential to agile success. How do you inspect and adapt your business analysis work to learn and develop?

Traditional Analysis

Agile Analysis Adaptation

Participate in milestone or project “lessons learned” sessions to find out what went wrong, what went right, and who is responsible for the problems. The project manager fills out the lessons learned template and writes the closeout document.
Sit with your manager once or twice a year for a performance review, and get feedback on your performance, months or weeks later. Sometimes that feedback includes second-hand comments from your customer and team.

Use acceptance tests, examples, sketches, simple drawings, and face-to-face communication to get feedback on your understanding of requirements.
Participate in daily stand-up status meetings to hear the impact you are having on other people’s ability to deliver.
On any given day, as an item you committed to deliver is deemed done, show it to the customer to get feedback on it and confirm that the conditions of satisfaction have been met.
Design and facilitate, or participate in, iteration and release retrospectives (every two or three weeks, depending on your iteration timebox) to learn what works, learn what to adapt, and collaboratively agree on one or two things to do differently in the next iteration or release. The goal is to learn, adapt, get better, and experience joy in your work.

The new world of agile analysis

So there you have it – a bird’s-eye view of how business analysts operate and add value in agile projects. As you can see, this approach calls on you to stretch your analysis muscles.

As an agile analyst, you are deeply committed to delivering business value and building the right product as soon as possible. As a member of an agile team, you are less concerned with roles and job boundaries, and more concerned with delivering as a team.

You experience the rhythm of successive elaboration and product delivery. You thrive on feedback and small, continual improvements. What’s more, you have an intense need to self-reflect, communicate transparently, improve your skills and abilities, and serve your team and customer. You thrive on the energy and joy of being in rhythm with an agile team.

Thanks!
The author would like to thank Phil Abernathy, Susan Block, Mary Gorman, Kamal Singh, Norman Stang, and Stephanie Weiss for their helpful review and feedback on a draft of this article.

(This article first appeared in Modern Analyst, May 2009)

Don’t forget to leave your comments below.

Ellen Gottesdiener is the Principal Consultant and Founder of EBG Consulting, Inc. She helps business and technical teams collaborate to define and deliver the product customers value and need. Author of two acclaimed books Requirements by Collaboration and The Software Requirements Memory Jogger, Ellen works with global clients and speaks at industry conferences. As an agile coach, trainer, and contributor to the agile IIBA BABOK^TM agile extension, Ellen is passionate about sharing the value of agile practices for analysis, and the discipline of analysis for agile value delivery. Learn more from her articles, tweets and blog, free eNewsletter and find variety of useful practitioner resources on EBG’s web site.

References

Gottesdiener, Ellen. The Software Requirements Memory Jogger: A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements. GOAL/QPC, 2005.

The Bad Ass BA Observes the “Hunt for the Right BA”, Part 2

Written by Cecilie Hoffman on February 8, 2011. Posted in Articles.

In the January article, I talked about the job seeker’s difficulty sorting through job descriptions for business analysts. In Part 2, I want to turn it around and look at the “specialist” vs. “generalist” question that we face as we create our resumes – how do we position ourselves as we respond to job postings?

In the Feb 2011 IIBA Newsletter, Laura Brandenburg, IIBA Career Center Product Manager, said, in her article, “5 Steps to Becoming a Business Analyst”

Although IIBA® holds us business analysts together under a unified understanding of business analysis, the real world of business analyst job roles is often messy and difficult. BA roles, as we learn in the competency model, fall into three main buckets:

Generalists, who perform a wide variety of business analysis activities
Specialists, who use a limited set of techniques or a single methodology
Hybrids, who do business analysis within another job role

I think there’s a little more to consider. We have to put the generalist vs. specialist discussion in the context of the course of our careers, entry-level, mid-career, experienced-and-having-too-much-fun-to-retire. Here are three typical patterns:

In Pattern 1 you began your career doing software testing in under watchful supervision. Your manager was pleased with your instinctive planning and thoroughness and arranged for formal training in quality assurance. Along the way you discovered use cases and the iterative development. You became a QA generalist for software products, often requested by product managers for “dot oh” releases. Over time, your role evolved into a business analyst role with a specialization in testing activities.

In Pattern 2, you were hired as a business analyst because that’s the title all straight-out-of-college entry-level technical people were given until the manager figured out what you were good at. You had no clue what the BA role was or how to do it. You were given all kinds of work to do, and by asking questions you just figured it out. Because you were able to establish a good working relationship with Group X, you became the go-to person for their application, helping them map their business processes, determining their requirements, designing the user acceptance tests, often coding the changes and jacking the new code into the release environment. A larger company that has better software deployment practices bought out your company; you are no longer allowed to hot swap modules into the production environment. Instead, thanks to your new ITIL Foundations certificate, you became the BA manager for the new group that absorbed Group X.

In Pattern 3, the specialist pattern, you came out of school with a strong database background. You hired into a company that was transitioning from an in-house built HR system to PeopleSoft and became a data migration SME in no time flat. Because you showed that unusual combination of communication and analysis skills, your role shifted from database developer to functional requirements specialist to HRIS business analyst. Over the years your knowledge of PeopleSoft has become greater, both in depth (the integration of PeopleSoft to the company’s ERP system) and breadth (all the different business teams that use PeopleSoft and their wide variety of needs). You started speaking at conferences and writing articles for trade journals. Eventually, you started your own consulting company and now you are traveling the world, helping other companies with their PeopleSoft projects.

There are risks and benefits to both being a generalist and a specialist by the time you are at mid-career. In a nutshell, the risk to being a specialist is that you may become so narrowly focused as to limit your career growth options. The risk of being a generalist is that you may be lacking in-depth knowledge that would make you instantly useful to a hiring manager. The benefit of being a specialist is that if you have the high-demand skills, the likelihood of spending much time on unemployment goes down. The benefit of being a generalist is that you see the patterns across organizations and industries – your big picture view can make you extremely valuable to the right employer. Moreover, an employer who is looking for a generalist is likely to have an expectation of teaming you with subject matter experts.

How can an IT BA become a generalist? In the world of IT, Business Analysts tend to cluster in one of four areas, infrastructure, applications, operations and project management.

Project Management. Glenn Brulé coined the term “PooMBA”, a person who is paid one salary to do two jobs. In some back water IT environments, BAs are still “junior PMs”. There are also BAs who are acquiring and refining their project management skills by voluntarily taking on these types of responsibilities.

Infrastructure. The business analyst who has a lot of infrastructure experience may have a specialist title, e.g., network specialist or security specialist. While their job description lists all the technical expertise they are expected to have, the description may gloss over the crucial role they play in communicating with other technical teams. Middleware specialists e.g., TIBCO developers often have an Applications Developer title. While their focus may be on the low level functional requirements, the knowledge and skills of requirements analysis, management and communication are still critical to the success of the projects.

Operations. In the world of Operations, business analysts are often found juggling change requests, release schedules, quarterly freeze exception requests with one hand, and SOx guidelines with the other. Their managers may not think of them as business analysts, but the knowledge area of business analysis planning and monitoring applies directly.

Applications. Business and technical applications are as plentiful as mosquitoes at your picnic at dusk. A ridiculously over-simplified view of the world would put business-level applications in one bucket, and everything else in the other bucket. By business-level applications I mean those in the class of Enterprise Relationship Management systems, e.g., Oracle, or Human Resource management systems, e.g., PeopleSoft, or Supply Chain management systems, e.g., SAP, or Customer Relationship management systems, e.g., Sales Force, and … those applications that support a business function that is specific to the type of organization, for example, many city governments use Azteca’s Cityworks. Many Business Analysts spend their entire career in one application!

Let’s look at Petra’s situation. Her most recent experience is five years of experience doing release management. Prior to that she had two years of application change request management as an entry level BA. She has been the release management team lead for the past year and after that very long year the job is no longer an interesting challenge. Petra is worried that she has become pigeon-holed in her job, that is, her manager assumes she’ll do release management forever. Petra knows the operations angle of her job very well, but she hasn’t ever worked on a business case, she has never done a solution assessment, let alone worked on a cross-functional strategic initiative. She’s really good at release management and she knows these skills would transfer well to another company. Should she branch out or should she stay focused in this one area?

She looks at her company’s job postings and sees one in the Network operations group. They need a business analyst with requirements management skills and some PM experience. She has no infrastructure experience at this point in her career, should she apply for the job?

There’s no right answer – only more questions to be asked – chief among them is whether she is interested enough to explore this new area. Some companies have good Human Resource staff that can ask her questions to help her make a decision. Petra can also talk to her manager about career development – a good manager is willing to help. She could also talk to the manager of the network project to find out if she might be a good fit. Maybe this isn’t the right project, but there will be others. And, it will give her current manager time to plan a transition. Talking to her colleagues can also be helpful – they may know of even better opportunities for what they perceive her strengths and interests to be.

Truth be told, I have a bias towards developing a broad base, I think that a wide range of experience gives a BA a qualitatively better perspective to assess risk and benefit. You could argue that while I’m a generalist business analyst, that is, I have no expertise in any applications or infrastructure technologies; I have also specialized in being a generalist. In the same breath, I could argue that a Finance BA who systematically becomes proficient with every module in Oracle ERP is a person who has generalized specialist skills in a single application.

There’s plenty of wiggle room in the specialist – hybrid – generalist model, which is one of the beauties and aggravations of Business Analyst position. There’s more to job-hunting than just responding to job postings and shaking down your LinkedIn network for leads. Think about what you want from your career, what you are curious about, what skills and experience you want to acquire to make yourself the right BA for the jobs that interest you as well as the right BA that the hiring manager is hunting for.

Don’t forget to leave your comments below.

Cecilie Hoffman’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She authored the 2009 Bad Ass BA series for BA Times and most recently the poem, A is for Analysis. See her blog on her personal passion, motorcycle riding, at http://www.balsamfir.com. [email protected]

The Bad Ass BA Observes the Hunt for the Right Business Analyst

Written by Cecilie Hoffman on January 25, 2011. Posted in Articles.

Like so many other people, I’m job-hunting. Job-hunting is never easy, even when you are doing it from the relative safety of having a job, but one that you would like to leave. In this era of the robo-online job postings, job-hunting feels particularly demoralizing because most companies do not provide any form of closure on your application. You apply, you get a robo-acknowledgement of your application and then you hear nothing for weeks and months. In four months of searching I have received exactly one email, machine-generated, that thanked me for my application and informed that the position had been filled. That organization went to the top of my list for, “keep an eye on them – they would be good to work for” because of the implication that someone had written a requirement to actually close the loop with applicants!

There are some good job postings out there, jobs that describe a position with required skills, experience and responsibilities that make sense for a business analyst. There are also a plethora of weird job postings wherein the job described seems either too narrow or too broad or suffering from role confusion. I’m seeing pattern in these less-than-optimal job postings. It seems that every company has their own definition of the role of the Business Analyst. From where I sit it is going to take more than a grass roots effort from the BA community to bring together the HR / hiring manager view of the BA and the IIBA’s vision of the BA. Here are four patterns in the job postings that cause me the most consternation:

Pattern #1: The “Bird in a Cage” model

Requirements jockey – We need you to handle proposal requests. You will write the BRD and throw it over the wall to the outsourced development team.

Requirements change control czar – “We need a patient, detail oriented, people-oriented person with excellent documentation skills.” Translation: you will be in the person that everyone complains to. The users and their managers will always be escalating; the development team will always be exhausted, and the auditors will always be looking for something to be wrong with the record keeping.

Pattern #2: The “Two for One” model

System Analyst / Business Analyst – “The successful BSA will drive end user experience innovation. Must have professional software development experience with front end web development (JavaScript, HTML, CSS, AJAX) and the ability collect requirements from stakeholders.”

Quality Assurance Analyst / Business Analyst – “You are the right person if you can model business processes, facilitate discussions and write detailed business requirements and use cases, facilitate walkthroughs of detailed business requirements and use cases, and perform functional tests.”

Project Manager / Business Analyst – “You are the right person if you can compartmentalize the perspectives and responsibilities of a PM and BA for a business owner who dithers. The last BA hired was great at dealing with the project stakeholders musing about changing direction, but her head exploded when she put on her PM hat and considered the ramifications to the project.”

Pattern #3: The “All in One” model

“You are the right BA for this company if your background includes an MBA, and MA in Information Science, and you have managed projects, and you have both IT and product development experience, and you have worked with marketing and sales teams and you are fluent in Mandarin Chinese, Russian, and Portuguese. 50% travel.”

Pattern #4: The “clone the 25-year veteran who just retired” model

“The right BA for us has experience in our customized PeopleSoft modules, can modify Business Intelligence reports, is familiar with SFDC, can do a mind meld with stakeholders, can hold the requirements traceability matrix in their head and can mentor junior business analysts.”

The IIBA is already working with PMI so that there will be a better understanding of the contributions of the two roles to future projects. Perhaps the IIBA might consider an initiative to work with Human Resources professional organizations as well. In my humble opinion more could be done to educate HR staff and hiring managers about the role of the BA. In many companies, “job reqs” (job requisitions) are drafted by the hiring manager and completed by an HR staff member. If that HR staff member were more familiar with the envisioned industry standard BA role, we might see fewer job postings like the ones above. In my ideal world, there would more consensus amongst companies about the role and value of the business analyst. Moreover that consensus would be in alignment with the IIBA vision, and we wouldn’t see job postings that leave us scratching our heads in bemused consternation.

Don’t forget to leave your comments below.

Is Your Business Analysis Process Like Buying a Car?

Written by Kupe Kupersmith on December 7, 2010. Posted in Articles. 2 Comments on Is Your Business Analysis Process Like Buying a Car?

This past weekend my wife and I bought a new car. I was replacing my 14 year old Ford Explorer and had 3 cars in my sights. I went to 3 dealerships to test drive those cars. What a nightmare! I thought the car buying experience was going to be better than 14 years ago. I actually think the process is worse.

With all the online tools available and my network of friends I did all the research. I knew which cars I liked, what the dealers pay for the cars and what people in my area have been paying for them. The first step I took was to submit my information on the dealership’s website, get a price quote and set up an appointment to test drive the car. For each dealership I received an automated email stating I was a preferred customer and when I arrived at the dealership I would speak directly to a manager. The manager would work with me to test drive the car and settle on a price. I was lead to believe I could expect to be in the dealership for 30 minutes to an hour. With my preferred customer number the dealership had all my information. What a great way to buy a car, right! Absolutely…if it actually went down like that.

When I arrived at the dealership, I was quickly moved to work with a salesperson who started to ask me what car I was interested in. He broke out a form and began asking me for my name, phone, address, email etc. I am a calm and patient person, but this set me off. This person knew nothing about me and it would take 30 minutes to explain what I already shared with the dealership online. I left the dealership letting them know I was not planning on buying a car from them. Could you believe 3 days later I received an email from the internet dept. of that dealership asking me if I was still interested in a car. Aah!!!! I was reminded why I don’t buy cars often.

Is your business analysis process like buying a car? I hope it is not close. Your process needs to be customer focused. I spoke with someone a few weeks ago and her organization was still in a “throw it over the fence” mode. That fence was so high and thick that she never received a question from the developer and was not even sure what the implemented solution looked like until it was in production. When she told me, the look on my face had to be saying, “Are you kidding me?” I assume her business stakeholders felt like me when buying a car. They shared information with the BA and then when the developer had questions they were probably asked the same types of questions..

At another company they did not throw it over the fence, but they still used a poor version of waterfall. The developers and QA team were not brought in at the beginning of the project. The BA would review requirements with the tech lead and QA lead that would then estimate the build and test portion of the project. If the high level estimate was approved developers and QA analysts were assigned. You think they had questions? Even if the questions were not asked directly to the business stakeholder, their time and money was being spent on a lot of knowledge transfer.

This extra time and some unnecessary back and forth with your business stakeholders does not help promote the value of Business Analysis. As the BA you need to raise your hand and demand some change if your project lifecycle is not customer focused. Your role is to help implement solutions to improve the business area you support. Always make sure your process is geared towards that goal.

Always be easy to deal with,

Kupe

Business Analysis Love Fest at BBC

Written by Kupe Kupersmith on October 25, 2010. Posted in Articles.

I just returned home from the Building Business Capability conference in Alexandria, Virginia. It was a co-located conference with the IIBA, the business rules community, and the business process community. A common belief among attendees was that the combination of these three communities was a marriage made in heaven. At the end of the conference Ron Ross stated, in so many words, that we have to stop focusing on gurus of software development and start focusing on building business capability. As you can imagine, all three camps are big believers in understanding what an organization needs to achieve its strategic goals. Software may enable that, but it is not always the main driver. I had the feeling we were at a Barak Obama campaign speech and the entire crowd was going to scream back, “Yes we can”.

There were three main points in time at the conference where I felt we were at a political rally. The first was at a presentation given by Barbara Carkenord and Elizabeth Larson. They spoke about a paper written in conjunction with the IIBA and PMI to highlight the overlap of the PMBOK and the BABOK. The tone of the presentation was to show how the PM and BA can work together, not against each other. The 100 plus in the crowd were ready to march behind Barbara and Elizabeth. I could sense that almost everyone wanted to shout “Amen” at one point.

Next was a presentation on Enterprise Business Analysis given by Jason Questor. He introduced us to the work being done by the IIBA on the subject. Most of the attendees there were in alignment that our business analysis skills allow us opportunities in the strategy arena within organizations. These skills give us the ability to go beyond project work. Jason told a story about Kathleen Barret, president and CEO of the IIBA, letting an audience know that she believes business analysts will grow up to be CEOs. Talk about a rallying cry!

The third was at the closing panel, where a number of the audience felt the three communities should band together. The IIBA viewed as the broader picture with specialties in business process and business rules. Many attendees were thrilled to have learned more about each community and couldn’t wait until next year’s conference. I could tell many did not want to leave and go back to reality.

I was among those that thought how great it was to all come together, and I think a similar conference should happen next year and beyond. We need time to come together and learn from each other. Now that we have all hugged and said our goodbyes the real work begins. It was easy for all us who believe in business analysis, business rules, and business process to agree.

But, why are there still so many individuals and companies not focusing on these areas? If we want to make large wholesale changes in our organizations, each of us needs to perform better every day. We need to continue to show our value to make the changes we all believe in. Many of us at the conference walked away with ideas on how to improve and make that change. Mark Jenkins, KPMG, said you don’t always have to ask for permission, just do something…anything. Gladys Lam, Business Rules Solutions, said “just do it”. She wanted to make sure we went out and tried some of the things learned at the conference. She pushed us to not worry about being wrong and that we will improve iteratively.

What are you going to do? Don’t stick with the status quo. I am hoping a year from now there are more stories of how our community has helped built better business capabilities.

Please use this as a forum to discuss stories of how you are showing your value. We can all learn from each other.

Kupe

Don’t forget to leave your comments below