Tag: Business Analysis

It’s the End of the Business Analysis World as We Know It

Written by Steve Blais on April 16, 2013. Posted in Articles. 3 Comments on It’s the End of the Business Analysis World as We Know It

Where Does the Business Analyst Go From Here?

Being the serialized story of Brian Allen and Ann Brady, business analysts, and their Adventures in the New Oder of Agile

Chapter 1 How it began

Now he was concerned. Brian had weathered pretty much everything the organization could throw at a business analyst from the early days when he had to fight just to make the role a viable position in the organization to the past few years when he was under constant pressure to take over project management jobs in addition to his business analyst work. Brian was flattered that they felt that he had the capability to do both jobs simultaneously, but his heart was in business analysis and he was afraid that if he diluted his efforts by also managing he would seriously impair the enterprise level project he was on. Besides he had already done the project management thing. It was interesting and challenging, but it wasn’t what he wanted.

Now things were changing once again. The project he was on was a long term, several year reconstruction of one of the primary internal systems. It was one of the first systems the company had built to provide internal control over sales, marketing, order processing and just about everything associated with the organization’s backbone. The system was the pride and joy of the CIO, Carl, who was on the team that developed the system twenty years ago and it took some convincing, and a bit of arm turning, for the CIO to finally admit that the system needed an overhaul. Since he identified so closely with the system, it was as though he himself needed an overhaul. As a result, Carl also looked at the way the organization had been developing software over the years and despite a highly successful record of on-time delivery, at least on the internal mainframe based systems, the CIO decided that perhaps the organization should segue into agile.

The web site maintenance had converted to an agile approach to software development a few years back and been successful after some bumps. There were some teams here and there on the periphery of the internal systems that were run with an agile approach, mostly in maintenance activities. But the primary systems, based on the trusty IBM computers and written in Good Old COBOL, with a smattering of Assembler Language Code, were still maintained in a structured software development approach patterned after the linear, waterfall, model. Major new efforts, like the overhaul of the purchase order system which took two years was also done the traditional way.

Since the entire backbone system of the organization was going to be rewritten – code, databases, architecture, even some new networks – Carl had decided that everything might as well get more “modern’ as well. They were even relocating various offices and departments.

So Brian was worried. He and Ann were the lead business analysts in the organization and from his understanding of agile and its mystiques; he was looking at the end of his career as a business analyst in the organization. Neither he nor Ann wanted to leave. Their roots ran deep in the organization. But Ken, the leading Scrum advocate, who had led successful Scrum teams and Theresa, the technical lead, who was a staunch Extreme Programming (XP) advocate, were both onboard with the software development conversion and had advised Brian and Ann independently that the services of the business analyst were no longer required in the New World.

It wasn’t pretty. Brian still shuddered when remembering the show down meeting when the CIO decided to give the green light to the New Order of Development. What was ironic was that Brian had been a vocal proponent of the overhaul of the old system and was instrumental in influencing the CIO and executive committee to launch the new program that appeared to signal the death of his own job. Brian in fact, with Ann’s help, had written the successful business case!

Brian, of course, protested loudly in front of Carl, Vince, the Vice President of Marketing and heir apparent to the CEO’s job, and Olivia the Vice President of Operations, asking how the teams were going to determine what they had to do for the new system.

“Do any of your programmers have experience with inventory turns or balancing a cash receipts journal?” Brian had taken accounting courses and even a CPA overview from the state CPA association to keep up to date on accounting.

“They don’t have to be experts,” Ken countered. “We have the experts in the business who can tell the developers (he emphasized the word to remind Brian how out of touch he had become) what needs to be done. It’s not a problem. It’s time the developers and the business cut out the middle man, er, person (acknowledging Ann) and let the solution meet the problem directly.”

Ann spoke up. ”I’ve spent years with both the developers and business people. I don’t think the developers care to sit in long meetings and discuss the intricacies and ambiguities of supply chains and customer service. They have always preferred to just get the facts: what they have to do to solve the problem.”

Ken responded before Ann could finish. “This is the New Order, Ann. The developers are going to get with it and learn about the business. They are going to learn negotiation and interaction. Things are changing. We’re taking the developers out of their development hovels and moving them across the aisle.”

“Even if they don’t want to go? Even if they prefer just to code?” Brian asked remembering the days when he started out as a programmer and worked with many peers who really didn’t want to talk to anyone in the business.

“Yes,” replied Ken. “That is the Way of Agile.” He said it with a slight reverence as though talking about an Eastern Philosophy like Zen. Brian thought he saw Ken put his hands in front of his stomach and bow slightly with a Yin and Yang symbol hovering over his head.

Ann recovered the floor. “And I have not seen many of the business people who will jump at the chance to spend all their time with the developers and sacrifice their daily jobs. They don’t understand how the developers need to hear the specifications. They don’t understand how to specify requirements.”

Ken, in his enthusiasm, jumped in again, “They don’t specify requirements. Requirements are dead.” Brian thought he heard an underlying meaning in that statement: “Business analysts are dead along with the requirements.”

Ken explained, “We use user stories now. We don’t do requirements. Not only are requirements inefficient, tedious, generally unworkable, and unreliable, they are also boring. User stories are easy enough even users can do them. And we are also making the whole burdensome change management system that has infiltrated everything in our culture obsolete. No more green and pink forms, no cumbersome on line system that people forget to update, no endless change management meetings with the CCB that doesn’t want to be there in the first place, no politics,” Ken’s voice was raising, sounding like a politician in front of a Labor Day political rally crowd. “There will be no more risk management exercises with a Risk Register maintained by a Project Administrator, no Earned Value graphs and charts and reports, and, consider this, sir,” he said addressing Vince, “no more project managers or PMO.”

Ken, and everyone on the table, knew that the PMO and to a large degree the whole project management structure of the organization had been a thorn in Vince’s side for years. Vince hated the paperwork and time consuming processes that the PMO had established to provide some semblance of control and prioritizing of the projects in the organization. Vince was known to protest loudly to anyone who would listen, especially his golfing buddy, Charles Evans, the CEO, “We’re losing ground to the new and faster and more agile competitors out there. They get to market much faster than we do. They have a more agile approach to product development. When we come in with a change, it’s either in response to a competitor’s move or to market demand. If we don’t act fast we lose market share (market share was an important issue to Charles). If I have to go through all this paperwork and committee approval and business analysis and requirements and stuff…it takes longer to get something approved than to just get it done!” And unfortunately, Brian knew that was true to a large degree, but he was also around in the old days when everyone in Management Information Systems (MIS), as it was called then, seemed to be working on the demand du jour with no order or priority or sense. Efforts were introduced and dropped, replaced by other initiatives from executives with higher political clout, or urgency, and then brought back out of their hiatus with the admonition that they should already have been done. It was chaos. Projects failed not because they were mismanaged but because of the conflicting priorities and the disorder in the assignment of resources and the frenetic communications channels. Everyone in the organization could talk to any programmer at any time to get anything done. Brian was somewhat proud of the work he and Ann had done in bringing order to the business process of managing organizational change. He never took Vince’s complaints too seriously because the system was working fine for the rest of the organization.

It was then that Brian realized that Ken was in cahoots with Vince and had Vince’s complete support for the New Order. And Vince, as the next CEO, had the political clout. It looked like the Organizational Change Management system that had run successfully for these many years was as doomed as well.

“And as for the business people, they will love being able to get their needs met immediately in the order that they want them met. They will be able to change their mind, change their needs, change their approach, try new things and then try something else without the imprimatur of fighting the system to get things done. We see a major increase in innovation because the barriers to creative failure will be removed.”

Brian wondered where Ken had picked up the phrase “creative failure”. He knew it won points with Vince.

Brian and Ann fought to hold down their frustration. They lodged all the objections they could muster, but to no avail. The New Order was coming to the Organization. And that meant that there was no place in the New Order of Things for either of them or any of their cohorts on the Business Analyst Team that he and Ann had struggled so long to set up.

Brian’s thought, unexpressed to Ann who was lost in her own downtrodden thoughts, was “I’m way too young to retire, and way too old to start over again in a different organization or a different career. Besides, I really, really, really love being a business analyst.”

Brian was now being summoned into Pauline’s office. Pauline was the head of the PMO to which the Business Analyst Team reported. As he walked down the corridor which seemed a lot longer this morning than ever before, feeling like he was walking to his own execution, he was wondering, “what happens now? Is there no place for a business analyst in the New Order of Agile?”

With a shudder, Brian gathered himself together and opened the door to Pauline’s office.

“Ah, Brian,” said Pauline, not really smiling. “We have to talk. I’ll be talking to Ann next.”

What is going to happen to Brian facing the Perils of Pauline? Will the Business Analysis Team and the Change Management System survive? What about Ann and the rest of the business analysts in the organization? Join Brian, Ann and the rest of the Business Analyst Team in the next episode of Brian and Ann and the New Order of Agile next month.

Don’t forget to leave your comments below.

Excerpted from the forthcoming book from John Wiley, The Agile Business Analyst due out the end of 2013

How to Fill the Potholes in your Business Requirements

Written by Amanda Bennett on April 16, 2013. Posted in Articles.

It is springtime in Ottawa, Ontario, Canada. Beautiful, glorious, Spring! Everywhere you look, the signs are there: frozen rivers are starting to flow, birds are returning and filling the air with their sweet melodies, snowbanks are shrinking, and…oh yes, potholes are showing up everywhere in the roads. As much as I try to avoid them, somehow they always get me. It takes a special breed of car to survive the tough Canadian winters. My Honda Civic is on it’s 10th year, 161,000 clicks, and still going strong.

Trying to avoid the springtime potholes is a fair analogy to a task that I am often asked to do as a Senior Business Analyst: reviewing and providing constructive criticism on business requirements written by someone else. A road filled with potholes can wreck your car, just as a poorly written set of business requirements can wreck a project. My job when reviewing business requirements is to look out for these potholes, make the writer aware of them, and provide suggestions on how to fill them.

Digesting business requirements written by someone else can be challenging, depending on the writers experience, knowledge, and ability, so to make things somewhat easier, I provide a template for my clients to use. Before they start their requirements, I will meet with them to explain how to use the template and to discuss any questions they may have. Using a template, I at least know the intent of all the sections of the document, and it gives a greater consistency to the documentation I have to review.

Once the written requirements are sent to me for review, I start by analyzing the document from beginning to end. One of the first things I look for are acronyms or business terms that have not been defined. This usually happens because the writer thinks that they do not need to elaborate on the use of terms internal to their business unit, but they forget to consider the audience of the document they are writing. Clear and unambiguous definitions of business terms are especially important to the developer, as they can have a direct impact on how they architect the system.

I also pay a lot of attention to the process diagrams of the current and future states. It is a very common mistake to omit the alternative paths to a process. It is understandable how this can happen. People assume that because the process usually happens a certain way, that they do not need to mention the other rare scenarios. Others may think they only need to describe the perfect world scenario, and forget to think of all the what-ifs. For a manual (non-computerized) process, unusual scenarios can be dealt with simply by communicating with those affected. When the process goes electronic, it is another story. The programming logic has to include all the alternative paths, or the system could fail spectacularly. This is a mind-shift for people that can take some getting used to.

When I am ready to dig into the detailed requirements, there are a few things I am on the lookout for. First of all, what I do not want to see are long, wordy paragraphs with several requirements buried within it. It may feel more natural to write this way, but not only is it painful to read requirements this way, it also greatly increases the likelihood that a requirement will be missed somewhere along the way, either during the development, or in testing. A much safer practice is to write each individual requirement separately, and give it an identification number. That way, even if a requirement does get missed during development, it will get picked up in the testing, assuming your test scripts have appropriate requirements tracing as well! That’s the topic of another post.

Secondly, I want to see a clear link between the in-scope deliverables laid out in the project charter, and the detailed business requirements. This is so important, because people can and will forget (perhaps conveniently sometimes) the original goals of the project, and before you know it, the scope of the project has grown exponentially. Believe me when I say, this is a crazy train that you do not want to be a passenger on. To create that linkage, what I will do is ID each of the in-scope deliverables, and use them as the parent IDs for the detailed “child” requirements. That way you know where each requirement is coming from.

Finally, I watch out for requirements that delve too deeply into design details without properly explaining the need behind it. This is a risky thing to do because when describing design details as a part of requirements, you limit the technical architect’s (or whatever you call that role) ability to design the best system to meet the client’s needs. That said, there may be cases where a specific design may be warranted, but the reason for that should be explained clearly. There are, in fact, some people who feel that requirements should not contain any design details at all, and only state the need. Others feel that not only is it ok to include design in the requirements documentation, but fully expect it. This is a contentious issue that I will not attempt to resolve here, but suffice-to-say that you should do your homework before you start writing your requirements. Find out what the practice has been in past projects, and what is expected of you now.

While this is not an exhaustive list of everything I am on the lookout for when I review someone else’s business requirements, this represents the bulk of my work. Hopefully you’ve read something new in this post, or at least can relate to what I’ve written.

If you would like to weigh in on this topic, please leave your comments below.

Business Analysis in the Modern Full-Service Agency

Written by Neels Ackroyd on April 9, 2013. Posted in Articles.

Since the 1970s, the role of Business Analysis in software development cycles has gained significant importance. However, the presence of the business analyst has also grown in the web development sphere (especially in larger agencies), but the exact role still overlaps in many departments within larger agencies. This article focuses on the Business Analyst’s role in web and digital development.

The diagram below depicts a typical agency workflow, with the inclusion of the Business Analyst’s role:

Essentially, the onus of a Business Analyst in an agency is to create a functional specification to:

Define the scope and get sign off from the client
This is to eliminate the catastrophe of the lack of agreement between the client and the agency, especially in terms of system functionality and general scope. This can cause immense strain and stress between an agency and its client. Typical strains include resources that have to be rebooked, budgets that dry up, demotivation from production teams and late delivery within the client’s space.
Define guidelines to developers and designers
Functional System Specifications have to be fleshed out in the most detail possible for other team stakeholders such as designers and developers to be fully aware of all the system specifications.

From a design perspective: Ultimately, a wireframe should never limit the designers’ creativity, but rather encourage further innovative thinking by providing a framework for creativity. As reality speaks, budget and time are always on the scale, which does not mean creativity must be undermined, but rather controlled. Designers are thus still allowed to use the wireframes as a guideline, rather than a system set in stone.
From a development perspective: Functionality is defined and finalised upon sign-off of the Functional System Specification. It is therefore the duty of the technical lead to ask all questions before the document is delivered to the client. Having said this, if functionality changes due to improvements during design (or other discoveries), then change requests have to be written as addendums to the signed off functional specification.

It is very beneficial for Business Analysts to have a development and technical background so that best practices (for example technology preferences and database design) can be proposed. It also saves time for developers due to development groundwork that is done before development commences.

In conclusion, it is clear that the Functional System Specifications can be used in the master document for Production and if followed correctly, it will save the agency and the client a great deal of money, time and energy.

In my next article I will discuss best Functional System Specification guidelines for the modern digital agency.

Don’t forget to leave your comments below.

The BA Practice Lead Handbook 5 – Getting Organized. What Structure is Right for You During the Start-up Phase?

Written by Kathleen B. Hass, PMP on March 19, 2013. Posted in Articles.

A center of excellence is a team of people that is established to promote collaboration and the application of best practices. Centers of excellence are emerging as a vital strategic asset to serve as the primary vehicle for managing complex change initiatives.

Centers of excellence exist to bring about an enterprise focus to many business issues, e.g., data integration, project management, enterprise architecture, business and IT optimization, and enterprise-wide access to information. The concept of centers of excellence (COE) is quickly maturing in twenty-first century organizations because of the need to collaboratively determine solutions to complex business issues. Project management offices (PMO), a type of COE, proliferated in the 1990s as a centralized approach to managing projects in response to the challenges associated with complex projects in an environment with low levels of project management maturity and governance.

Business Analysis Centers of Excellence

The business analysis center of excellence (BACOE) then, is an emerging best practice, a new type of center which serves as the single point of contact for business analysis practices. In that role, the BACOE defines the business rules, processes, knowledge, skills and competencies, and tools used by the organization to perform business analysis activities throughout the project life cycle, from strategic planning to project initiation to solution delivery and benefits realization.

As the discipline of business analysis becomes professionalized, it is no surprise BACOEs are quickly emerging. Staffed with knowledgeable business and IT team members, these centers are fulfilling a vital need in organizations today – providing a business-focused home for current business analysis practices, technologies, and emerging trends. The BACOE serves as an internal consultant and information broker to both the project teams and to the executive management team. In addition, the BACOE is responsible for continuous improvement of business analysis practices. To that end, the BACOE continually evaluates the maturity of business analysis and implements improvements to overall business analysis capability.

Implementing the BACOE

Referring again to the BA Practice Framework, we assume you have completed the Readiness Phase, and are now ready to begin to implement the BACOE.

There are several models of BACOEs that are in existence today. Each structure has unique composition, goals and outcomes. The type of center that is most appropriate for your organization depends heavily on the culture, power and politics that exist within your organization. Common BACOE structures include those described in the table below.

BACOE Scope

A truly comprehensive BACOE is broadly scoped to include the services, functions, tools and metrics needed to ensure the organization invests in the most valuable projects, and then delivers the expected business benefits from project outcomes in terms of value to the customer and/or wealth to the organization. A full-service BACOE typically performs the functions described below.

A fully functioning BACOE is capable of providing services across the gamut of business analysis practices. The BACOE mission and objectives are met through training, consulting and mentoring business analysts and project team members, by providing BA resources to the project teams, by facilitating the portfolio management process, and by serving as the custodian of BA best practices. The BACOE generally performs all or a subset of the following services.

• BA Standard Practices and Tools – provides standard business analysis practices

- Methods – defines the methodology, metrics and tools for use on all strategic projects within the organization.
- Knowledge management – maintains the central historical data base of business analysis standard tools, processes and business architecture components
- Continuous improvement – periodically evaluates the maturity of the business analysis practices within the organization, and implements improvements to policies, processes, tools and procedures

• BA Professional Development – provides professional development for business analysts

- BA career path – along with the Human Resources Department, designs and maintains the BA competency model including titles, position descriptions, functions
- Coaching and mentoring – provides mentoring services to BAs and project teams to help them meet the challenges of their current project
- Training and professional development – provides formal skills and knowledge assessments, and education and training for the professional development of BAs
- Team building – provides team building experiences to project managers, business analysts, and team members

• BA Professional Services – serves as a group of facilitators and on-the-job trainers who are skilled and accomplished business analysts to provide business analysis consulting support including:

- Conducting market research, benchmark and feasibility studies
- Developing and maintaining the business architecture
- Preparing and validating the business case
- Eliciting, analyzing, specifying, documenting, validating, and managing requirements
- Managing requirements verification and validation activities, e.g., the user acceptance test
- Preparing the organization for deployment of a new business solution
- Providing resources to augment project teams to perform business analysis activities that are under-resourced or urgent

• Full Cycle Governance – promotes a full life-cycle governance process, managing investments in business solutions from research and development to operations. Provides a home (funding and resources) for pre-project business analysis and business case development.

- Business program management – works with management and the portfolio management team to implement a twenty-first century model that transitions organizations from stand-alone IT project management to business program management.
- Strategic project resources – provides senior-level business analysts to lead the business analysis effort for strategic initiatives.
- Enterprise analysis – provides process coordination and meeting facilitation to the portfolio management team. Conducts enterprise analysis activities and prepares the project investment decision package consisting of the business case, the results of studies and other supporting information that provides senior management with a clear understanding of what business results are to be achieved through a major investment.
- Benefits management – Measures the business benefits achieved by new business solutions; facilitates the adoption of a shared vision of the benefits realization process, manages the investment throughout the project life cycle and after the solution has been delivered.

Putting it all Together

So what does this mean for the Business Analyst?

Today’s BAs are performing their duties in a myriad of organizational environments. Determine where your organization is on the continuum and get involved in moving your BA practice to the next level.

So what does this mean for the BA Practice Lead?

This article presents the case for a BA Practice Lead to examine the organization to determine the best fit for the BACOE. Perhaps a less formal COE is appropriate at this point in time to build the foundation and credibility needed to implement a formal BACOE. Leverage the existing structures and power bases to launch your BACOE, constantly demonstrating the value of a mature BA practice.

Parts of this article are adapted with permission from The Business Analysis Center of Excellence, The Cornerstone of Business Transformation by Kathleen B. Hass, PMP, Richard Avery, Terry Longo, and Alice Zavala. © 2007 by Management Concepts, Inc. All rights reserved.

Don’t forget to leave your comments below.

Business Analysis: Art and Science Together

Written by Greg Kulander on February 26, 2013. Posted in Articles.

This is the last of a four-part series exploring whether ‘business analysis’ is art or science. This week we’ll talk about why business analysis is the synthesis of both art and science.

Over the past three articles we’ve asked “Is Business Analysis art or science?”

Cathy Brunsting talked about how the science of business analysis has developed in the past few years, with the advent of the International Institute of Business Analysis (IIBA), a professional organization dedicated to the profession. The Business Analysis profession now has a body of knowledge and certification, which helps to insure that its practitioners are meeting the standards of the profession. There are new ways to measure the competency level of an organization’s BAs. Plus, there are tools and templates available to aid practitioners in following repeatable processes.

Jeanna Balistreri, Char Ceci and Alan Smith talked about the art of business analysis by demonstrating how the profession requires creativity, communication and other soft skills in order to insure a successful project. They find that Business Analysis is about people and interacting effectively with a myriad of personalities. There is an art to the way that the BA applies available skills and tools that varies from project to project.

In the end, as Greg Kulander had already discovered in his business analysis career, there are elements of both art and science in the successful practice of business analysis. Both aspects are critical to the success practice of business analysis.

Without the science (which brings process, techniques, templates and measurability), the business analysis field would never have become a recognized profession that commands the respect of fellow professionals. Too often in the past Business Analysts (BAs) were perceived as little more that note takers or junior Project Managers because we could not articulate the science and discipline of our profession. There was little effective training and no repeatability in the process. Without science, every new BA would fumble around while gaining the experience and skills necessary to effectively practice the profession – much like Cathy and Greg did early in their careers.

The recognition of the profession from the IIBA organization as well as the CBAP and CCBA certification programs means that employers now recognize that there is science behind the profession which helps the industry increase the value of the BA role. BAs can be trained in the science of their profession and can demonstrate that they have the repeatable skills that are necessary to drive process. We now have empirical evidence to support higher salaries and better career paths for BAs with formal training and professional experience.

However, without the art to recognize that every project is different and that it takes creative skill to successfully navigate all the people, personalities, and pitfalls that all projects face, the science of our techniques and processes would be almost useless. It’s the art that prevents the BA from being ‘just a note taker,’ rigorously filling out our templates, with no real understanding of the problem that the business needs to solve.

By practicing the art of business analysis, the BA adds value to the team and to the process that goes well beyond the science of the profession. The BA becomes a bridge – the ‘hub of the wheel’ – enabling the business users and the IT team to work together collaboratively. The BA helps to insure that the team is developing a business solution that truly meets the business stakeholders needs and is feasible to be developed in a timely way by the IT organization. Practicing the art of business analysis elevates the BA to a leadership role, opening up better opportunities and career paths for the BA.

Science means that as BAs we have process, tools, and templates that bring the ‘state of knowing’ to our profession. Art allows us to use our ‘skills acquired by experience, study, or observation’ to choose the correct scientific tools and then apply our soft skills to insure that our projects are successful. In the end we find that business analysis truly is the synthesis of science and art.

Don’t forget to leave your comments below.

About the Authors:

Jeanna Balistreri is a Sr. Business Analyst at Geneca, a custom software development company. Jeanna has over 10 years of experience in various IT roles such as Project Management, Process Re-engineering and Business Analysis. Jeanna’s core competency is focused on bridging the gap between business and technology in order to help solve business problems through technology solutions. Currently, her focus at Geneca is centered on successfully delivering software through the Getting Predictable principles.

Cathy Brunsting is a Senior Business Analyst at custom software development firm, Geneca (www.geneca.com). She has over twenty-five years experience in all aspects of business analysis, systems development and project management, from project inception to customer acceptance. She is skilled in the analysis of business problems, as well as the design, implementation, testing, and on-going support of technical solutions. Her areas of expertise include Insurance, Interactive Solutions, e-Business Solutions, Financial Systems, Gaming and Lottery Systems, Telecommunications (Operator Console, Voice Recognition, and Call Processing), Order Entry/Subscription Services, and Database Design. Ms. Brunsting was also the founding President of the Chicagoland chapter of the International Institute of Business Analysis™ (IIBA).

Ms. Ceci has over fifteen years experience in all aspects of business analysis and project management. Her proven ability to streamline processes, rapidly define requirements, control scope, mitigate risks, and delegate tasks results in the implementation of powerful systems. She builds high-performing teams with local, virtual and off-shore resources. Known for her excellent cross organizational communication and problem solving skills consistently leads to exceed expectations. Ms. Ceci is a Senior Lead Business Analyst at the Chicago-based custom software development firm Geneca, and plays an instrumental role in the adoption and success of Geneca’s business analysis best practices.

Greg Kulander is currently a Senior Business Systems Analyst at custom software development firm, Geneca L.L.C., and is the Vice-President of Communications for the Chicagoland Chapter of the International Institute of Business Analysis. He has been working primarily as a Business Analyst on software projects since 1999 for such companies as JP Morgan Chase, U.S. Bank and NAVTEQ (now Nokia Location Services). He has helped lead successful projects in government, healthcare and private sector e-commerce, and was a founding member of the U.S. Bank Business Analysis Center of Excellence. He has a Masters degree in Management Information Systems from Benedictine University, and Bachelor’s degree in Marketing. Greg thoroughly enjoys seeing a project go live and watching an organization reap the benefits of well-made software!

Alan is a Senior Business Analyst who works for custom software development firm, Geneca. Alan has 12 years of technology experience working with various Insurance systems, Financial Systems, Telecommunications and Digital Entertainment. Alan is experienced with project definition, business analysis, requirements facilitation and analysis, quality assurance and all phases of testing. Alan specializes in Agile methodology, including XP, Scrum and Lean. Alan holds a Masters Degree in Adult Therapy from Loyola University Chicago. Alan loves building strong client relationships, and showing his clients how their engaged input into the requirements process will make their projects successful.