Tag: Requirements

CBAP Certification: From What is It? to I Did It!

Written by Cynthia Low on March 14, 2008. Posted in Articles.

The business analyst (BA) role has become essential in today’s workplace as a vital component of a successful project. The business analysis field has been accelerating at a rapid pace, and this acceleration has caused some understandable growing pains. Among the challenges are a lack of standardization, inconsistent terminology across organizations, and difficulty in assessing knowledge and skills of BAs.

The International Institute of Business Analysis (IIBA) was founded as a non-profit organization to promote the growth and professionalism of business analysis. Part of IIBA’s mission is to document and maintain standards for business analysis, and to recognize and certify practitioners. The CBAP (Certified Business Analysis Professional) certification program was put in place in 2006 to screen, test, and certify qualified and knowledgeable BAs.

This article briefly summarizes the CBAP program, and why business analysts should become certified. The majority of the article covers the steps and several tips to help you become certified.

IIBA and Certification

The IIBA was formed in 2003 as a non-profit organization devoted to creating awareness and recognition of the importance of business analysis. Part of IIBA’s vision is to build its image and become identified as the professional organization for BA professionals. It is also focused on identifying BA skills and competencies, and certifying practitioners based on them.

In fact, the IIBA’s mission is to “Develop and maintain standards for the practice of business analysis and for the certification of its practitioners.” One of the main creations of the IIBA has been its Business Analysis Body of Knowledge (called the BABOK for short or sometimes just the BOK). The BABOK is a guide to the generally accepted knowledge and practices in the BA profession. The other significant creation has been the CBAP certification: Certified Business Analysis Professional. The authors are proud to be among the world’s first CBAPs.

The CBAP certification process came from a BA task analysis study done back in 2006. From that, a committee of experts developed examination questions to test the business analysis knowledge and its application by BAs. Along with a rigorous application process, the examination is used for assessing and certifying experienced and knowledgeable BA practitioners.

In the spirit of the CBAP exam, and to start preparing to pass it, we’ve assembled a few basic multiple choice questions. These questions are typical of those on the exam—they are not from the exam. The answers are revealed at the end of the article.

Here’s the first of the questions; go ahead and see how you do!

1) The BABOK defines Business Analysis as:
A) Analyzing business problems and determining which projects will best solve those problems.
B) Identifying business needs and determining solutions to business problems.
C) Verifying business requirements by ensuring the solution meets business needs.

Certification Requirements: How do You Stack up?

Five years (7,500 hours) of business analysis work in the last 10 years

Demonstrated experience and knowledge in 4 out of 6 BABOK™ Knowledge Areas

21 hours BA professional development in last 4 years

Minimum high school education

Two work references

Application Process

The IIBA made the CBAP application process a rigorous one, to screen out under-qualified and less-experienced BAs. Check out the basic qualifications in the sidebar to the right. IIBA’s website has a comprehensive Frequently Asked Questions document about the CBAP process. Visit www.TheIIBA.org for more information.

Tip: The CBAP application can be tedious to complete. Use the thetemplate that IIBA provides to document your work experience and project hours.

To take the CBAP exam, your application must be pre-approved. The professional development hours must also be complete before applying. This requirement has prevented more than a few otherwise-qualified applicants from being allowed to sit for the exam. Make sure you can document your education hours with a certificate or other written proof.

Benefits of CBAP Certification

Given the strict requirements and rigorous application process, one would assume the certification is worthwhile, right? Well, as a matter of fact it is. There are a number of benefits that IIBA has identified to organizations to certify their BAs through the CBAP designation:

Employee development and recognition is enhanced.
CBAPs have signed a Code of Conduct, which increases the professionalism of its adherents.
CBAPs are identified as individuals with an advanced level of knowledge and qualifications, and follow established standards, making them a good choice for critical projects
CBAPs produce reliable, quality results with increased efficiency and consistency
Employers have a reduced risk in hiring and promoting people with the CBAP credential.

IIBA has also identified several benefits for you to become CBAP certified:

Demonstrates dedication and commitment to the business analysis profession
Ability to enhance the profession and have a voice among other professionals
Expedited professional advancement because the CBAP sets individuals apart
Demonstrates knowledge and skills necessary to be an effective business analyst
Advanced career potential – without having to become a Project Manager!
Opportunity to earn more income
Be recognized by the organization and peers as experts in their field.

The CBAP Exam

Hopefully, you can see there are many benefits for you or others at your organization from BA certification. To help you get started, here is some valuable information about the exam and tips for passing it.

As of the date of this article, the CBAP exam is a collection of 150 multiple-choice questions. Some are simple and straightforward, some are downright difficult, and most are challenging. The exam will be“going electronic in mid-2008, but for now it is paper-and-pencil based. It is also held in a few select cities. The IIBA web site contains current and future exam dates.

The exam duration is three hours, and you may find that you need most or all of that time. Because of the length, some people find it useful to start the exam by noting a few key mnemonics and definitions. If nothing else, this “brain dump” helps alleviate a little test anxiety that many people feel in a high-stakes exam like the CBAP. We’ve recommended this same technique for years to people preparing for the PMP exam.

Tip: do a “brain dump” of key concepts at the start of the exam to help clear your brain, reduce test anxiety, and to serve as a reference as you take the exam.

OK, ready for another exam question?

2) The BABOK defines a Business Analyst as someone who:
A) Translates business needs into a design that can be implemented by the development team.
B) Responds to client requests and provides solutions that best meet those needs within time and cost restraints
C) Elicits, analyzes, communicates, and validates requirements for changes to business processes, policies, and information systems.

BABOK Overview

The CBAP exam is heavily based on the BABOK guide. There are some exam questions not strictly found in it, but thoroughly knowing the information in the guide is the surest way to pass the exam. The BOK has over 300 pages of often-detailed tasks, inputs, outputs, and techniques. It is helpful to have a plan and tools for breaking the BABOK down into logical pieces for memorization and study.

To start you off breaking down the BABOK, here are highlights of it and some key areas to study.

Tip: Start by memorizing all the Knowledge Areas (KAs for short). Then work on memorizing tasks with each KA. Some have too many, so start with KAs having only a few, like Enterprise Analysis and Elicitation, and work up from there.

Enterprise Analysis

This KA focuses on identifying business opportunities through feasibility studies, creating business cases, cost/benefit analysis, etc. It covers looking at the big picture through building a Business Architecture framework, in order to later integrate requirements into it. Plus, it can provide a context or foundation for evaluating future projects, issues, and changes. There are only six tasks in this KA, so you are advised to memorize them and their order.

Goal: Facilitating the optimum project investment path for the enterprise.

Requirements Planning and Management

The next KA deals with resources and tasks for planning and managing requirements activities throughout the “requirements process.” It identifies a myriad of activities and deliverables, and we advise you not to try and memorize them all. Instead, organize the tasks into logical groups, such as Team Roles, Risk Approach, Manage Requirements Scope, etc. The chapter also covers planning for how changes are controlled and managed, and begins the process of prioritizing requirements.

Goal: Organize the requirements effort, including resources, monitoring, project coordination, and changes.

Tip: Study the most on Enterprise Analysis and Requirements Planning and Management, because they comprise the highest proportion of exam questions, according to the IIBA.

By now you may be ready for another exam question!

3) The BABOK defines a Requirement as:
A) A condition or capability of a product or solution that documents a problem or objective of the business.
B) A need or necessary feature of a system that could be sensed from a position anywhere within the system.

Requirements Elicitation

Requirements must be elicited from stakeholders in order to be analyzed and documented. This KA covers the process, tasks, and techniques for doing just that. There are ten techniques to be familiar with, such as brainstorming, interviewing, requirements workshops, etc. Make sure you know all ten of the techniques, including the strengths and weaknesses of each and how to perform them. Prioritize your time by concentrating on the most important techniques like interviewing.

Goal: Use appropriate techniques to elicit complete and accurate requirements.

Requirements Analysis and Documentation

Considered by many to be the “core” of what a BA does, Requirements Analysis and Documentation deals with how stakeholder needs are analyzed, structured, and documented. The understanding is that the ultimate goal of business analysis is for later use in designing and implementing a solution.

To represent commonly accepted practices, this BABOK KA covers 20+ analysis and documentation techniques. While you may not have used every one, you are expected to be able to answer questions about them. There is an emphasis on modeling techniques, so make sure you know them, like data modeling, use case modeling, etc. Learning about new techniques is one of the many ways that the CBAP certification process helps us improve as BAs.

Goal: Have a clear enough understanding of the requirements to enable building a solution to meet business needs.

Tip: When preparing for the exam, the terms used in the BABOK won’t always be the terms you’re used to on the job. Make sure you know and memorize the BABOK’s terms if you want to pass the exam, even if they are “wrong.”

Requirements Communication

For requirements to be valid and approved, they must be communicated. This can and should happen throughout the life cycle of eliciting, analyzing, and documenting them. The Knowledge Area on requirements communication focuses on expressing the output of requirements analysis and documentation. It covers the need for presenting requirements in formats suitable for your intended audience.

Goal: Achieve a shared understanding of and agreement to the product requirements.

Solution Assessment and Validation

Once requirements have been approved, they need to be implemented to be of value. To do this, BAs work to ensure the best solution is chosen (i.e., requirements are fulfilled by a technical design). The BABOK also mentions, but does not elaborate on the QA process, and that BAs contribute to test plans and testing process. Also covered in this KA is the role played by BAs to facilitate the implementation and help resolve any post-production issues.

Goal: Ensure the final solution meets business needs and can be implemented.

Tip: The BABOK is a long document, so make sure you leave plenty of time to read, study, and memorize key parts of it. Get plenty of rest before the exam; sleep will help you more than cramming!

Breaks are essential to learning and memorizing complex material, and to break down the important parts of the BABOK.

To give you a break right now, it’s time for another question:

4) When developing alternative solutions, how do BAs record the process of flowing from requirements to design:
A) Map the Requirements to the Design.
B) Determine Number of Design Phases.
C) Map Requirements to Design Phases.
D) Update Requirements Traceability Matrix.

Underlying Fundamentals

The knowledge and skills described in the BABOK don’t happen on their own. BAs need many other underlying skills in order to perform the tasks identified in the BOK. There is no explanatory information to study, so you must rely on general knowledge of business, communication, management, leadership, and problem solving.

Goal: Improve effectiveness in doing our jobs.

In summary, the authors believe that CBAP certification will be the next “in demand” certification for people doing project-related work. This will be primarily Business Analysts, but Project Managers, Systems Analysts, QA Analysts, and even Application Developers will want to explore the CBAP. The future of business and technical careers will belong to people who are adept at communicating, analyzing, solving business problems, and producing enduring results. Those who “earn” the CBAP designation will also be the ones to “earn” more financially, as well.

Tips: To prepare for the CBAP exam, here are some final thoughts to help you pass it:

Read the BABOK completely
Take a prep class to help focus on key areas
Join a study group to concentrate on one KA at a time
Take practice exams
If time, re-read portions of the BABOK you had trouble with in practice exams

Here are the answers to the sample exam questions: 1 b), 2 c), 3 a), 4 d)

IIBA, CBAP, and BABOK are registered trademarks of the International Institute of Business Analysis.

Elizabeth Larson, CBAP, PMP and Richard Larson, CBAP, PMP are Principals, Watermark Learning, Inc. Watermark Learning helps improve project success with outstanding project management and business analysis training and mentoring. We foster results through our unique blend of industry best practices, a practical approach, and an engaging delivery. We convey retainable real-world skills, to motivate and enhance staff performance, adding up to enduring results. With our academic partner, Auburn University, Watermark Learning provides Masters Certificate Programs to help organizations be more productive, and assist individuals in their professional growth. Watermark is a PMI Global Registered Education Provider, and an IIBA Endorsed Education Provider. Our CBAP Certification Preparation class has helped several people already pass the CBAP exam. For more information, contact us at 800-646-9362, or visit us at www.WatermarkLearning.com.

Fill-in-the-blanks: A Process / Content Framework

Written by Terry Longo on February 15, 2008. Posted in Articles. 1 Comment on Fill-in-the-blanks: A Process / Content Framework

If you’ve read the previous entries in this blog, you have seen that we’ve been building up to something, and this new entry will hopefully bring us to our first conceptual plateau, upon which there is much more to build.

What we’ve done so far is to reorient our view of requirements and the BABOK, by going from this (based on BABOK 1.6):

to this (based on IIBA guidance on BABOK 2.0 direction and the concepts from the three previous blog entries):

Following the previous blog entry about content vs. process, we are naturally led to the above structure which manifests that distinction and also provides a framework within which we can indicate the appropriate methods, tools, techniques, and standards for the corresponding process phase, within the corresponding language domain.

For example, in the Software Development x Elicitation cell, we would typically find UML, prototyping, consideration of legacy systems, etc.; while in the Enterprise e-Learning Infrastructure x Elicitation cell, we might find multimedia complexity requirements analysis, consideration of training data privacy laws, task analysis, etc.

This view brings up some interesting questions about

Ownership of the process itself (process design, continual improvement, and governance)
Whether this view contributes to or hinders senior management’s ability to obtain a dashboard view of the benefits, costs, and risks related to current requirements management efforts
The potential benefit to the enterprise as a whole should this view be adopted by managers and individual contributors involved in managing or meeting requirements

We’ll tackle one of those in the next entry. Meanwhile, I, and I am certain your colleagues, would love to hear your comments.

The Impact of Business Requirements on the Success of Technology Projects

Written by Cynthia Low on February 15, 2008. Posted in Articles. 1 Comment on The Impact of Business Requirements on the Success of Technology Projects

Findings Review

Business requirements serve as the ultimate blueprint for IT project success. That’s no big surprise. What might surprise many are the contents of a first-of-its-kind Business Analysis Benchmark Report by IAG Consulting. Among other things, the report found that companies with poor requirements definition and management spend on average $2.24 million more per project on their major projects.

The Business Analysis Benchmark Report presents the findings from surveys of over 100 companies and definitive statistics on the importance and impact of business requirements on enterprise success with technology projects. The survey focused on larger companies and looked at development projects in excess of $250,000 where significant new functionality was delivered to the organization. The average project size was $3 million. The study has three major sections:

Assessing the Impact of Poor Business Requirements on Companies. Quantifying the cost of poor requirements.
Diagnosing Requirements Failure. A benchmark of the current capability of organizations in doing business requirements and an assessment of the underlying causes of poor quality requirements
Tactics for Tomorrow. Specific steps to make immediate organizational improvement.

In addition to the full text report, these sections have also been published as stand-alone white papers for ease of use. All can be accessed from www.iag.biz.

The study provides a comprehensive analysis of business requirements quality in the industry and the levers for making effective change. The following issues are addressed in the report: the financial impact of poor quality requirements; the information needed to identify underlying issues critical to success; and, the data necessary to target specific recommendations designed to yield performance improvement.

The report finds two basic scenarios for companies:

a) Scenario 1: Project success is ‘Improbable’. Companies might be successful on projects, – but not by design. Based on the competencies present, these companies are statistically unlikely to have a successful project. 68% of companies fit this scenario.
b) Scenario 2: Project success is ‘Probable’. Companies where success can be expected due to the superior business requirements processes, technologies, and competencies of people in the organization. 32% of companies fit this scenario.

Almost everyone understands that requirements are important to project success. The data above demonstrates that, while people understand the issue, they did not take effective action in almost 70% of strategic projects.

Effective Business Requirements are a process – not a deliverable. The findings are very clear in this regard – companies that focus on both the process and the deliverables of requirements are far more successful than those that only focus on the documentation quality. Documentation quality can only assure that investment in a project is not wasted by an outright failure. The quality of the process through which documentation is developed is what creates both successes and economic advantage. To make effective change, companies must rethink their process of business requirements discovery.

The following are a few key findings and data from the study:

Companies with poor business analysis capability will have three times as many project failures as successes.
68% of companies are more likely to have a marginal project or outright failure than a success due to the way they approach business analysis. In fact, 50% of this group’s projects were “runaways” which had any 2 of:
- Taking over 180% of target time to deliver.
- Consuming in excess of 160% of estimated budget.
- Delivering under 70% of the target required functionality.
Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their projects.
Over 41% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization.
The vast majority of projects surveyed did not utilize sufficient business analysis skill to consistently bring projects in on time and budget. The level of competency required is higher than that employed within projects for 70% of the companies surveyed.

Almost 70% of companies surveyed set themselves up for both failure and significantly higher cost in their use of poor requirements practices. It is statistically improbable that companies which use poor requirements practices will consistently bring projects in on time and on budget. Executives should not accept apathy surrounding poor project performance – companies can, and do, achieve over 80% success rates and can bring the majority of strategic projects in on time and on budget through the adoption of superior requirements practices.

Making Organizational Improvement

The survey findings made it clear that there is no single silver bullet for making organizational improvement. CIOs must look at making improvement across all the areas of people, process, and tools used to support processes to gain organizational improvement. Only a systematic change to all areas of people, process and enabling tools yields material improvement. 80% of projects from the companies which had made these broad-based changes had successful projects.

The findings of the Business Analyst Benchmark describe both the poor state of the majority of companies surveyed, and, a path to performance improvement. To assist the executive reader, this report also analyzes the data for alternative actions which could be taken to make improvement to separate myth from actions that create benefit. The top three findings in this area can be used to change business results:

80% of projects where successful from companies with mature requirements process, technology and competencies.
Auditing three 3 specific characteristics of business requirements documentation and forcing failing projects to redo requirements will eliminate the vast majority of IT development project failures.
Elite requirements elicitation skills can be used to change success probabilities on projects.

These above survey findings and the underlying statistics are described in detail within the report. Overall, the vast majority of companies are poor at both establishing business requirements and delivering on-time, on-budget performance of IT projects. Satisfaction with IT and technology projects wanes significantly as the quality of requirements elicitation drops. This report is both a benchmark of the current state of business analysis capability, and, a roadmap for success.

The Bottom Line

The challenges in making quantum improvement in business analysis capability should not be underestimated. Organizations understand conceptually that requirements are important, but in the majority of cases they do not internalize this understanding and change their behavior as a result. The most successful of companies do not view requirements as a document which either existed or did not at the beginning of a project, they view it as a process of requirements discovery. Only companies that focus on both the process and the deliverables are consistently successful at changing project success rates.

For companies that have made the leap to the use of elite facilitation skills and solid process in requirements discovery there are significant benefits. Not only were these projects rarely unsuccessful, these projects are delivered with far fewer budget overruns and in far less time. The report describes the use of poor requirements process as debilitating. Using this word is perhaps unfair, since companies do not collapse as a result of poor quality analysis. In fact, IT organizations and the stakeholders involved will overcompensate through heroic actions to attempt to deliver solid and satisfactory results. However, ‘debilitating’ is an accurate word to describe the cumulative effect of years of sub-optimal performance in requirements analysis when results are compared to competitors who are optimal. Even leaving out the effect of high failure rates and poorer satisfaction with results, the capital investment in information technology of the companies with poor requirements practices is simply far less efficient than companies that use best requirements practices.

To illustrate this inefficiency of capital expenditure on technology at companies with poor requirements practices, use the average project in this study ($3 million):

The companies using best requirements practices will estimate a project at $3 million and better than half the time will spend $3 million on that project. Including all failures, scope creep, and mistakes across the entire portfolio of projects, this group will spend, on average, $3.63 million per project.
The companies using poor requirements practices will estimate a project at $3 million and will be on budget less than 20% of the time. 50% of time, the overrun on the project both in time and budget will be massive. Across the entire portfolio of successes and failures, the companies with poor requirements practices will (on average) pay $5.87 million per project.

The average company in this study using poor requirements practices paid $2.24 million more than the company using best practices.

If overruns are common at your company, or if stakeholders have not been satisfied with more than five of the last ten projects larger strategic projects, there is definitely a problem and your company is likely paying the full poor requirements premium on every project.

Keith Ellis is a Vice President at IAG Consulting, specialists in eliciting and managing business requirements for technology initiatives. Mr. Ellis was co-founder of the elicitation company Digital Mosaic (merged with IAG in 2007) and has extensive experience in technology research, business analysis issues. He regularly publishes articles, white papers and other research findings in these areas. Mr. Ellis can be reached at (905) 842-0123 x228. Email IAG by accessing www.iag.biz and selecting contact us or call our North American Toll Free line: 800-209-3616

Road to the Perfect Project Part 3

Written by Cynthia Low on February 15, 2008. Posted in Articles.

Limit Formal Process

Many projects today, especially the larger, ones are run based on what I call “big process”. Development organizations get their systems and software engineering processes and procedures CMM/CMMI certified. This means that anyone working on their projects lives in a world controlled by a myriad of plans and processes covering all aspects of that project. Projects in these organizations will also be documentation heavy – typically based on IEEE standards. There are very good reasons for the existence of big process. These processes represent best practices distilled from decades of corporate experience. Big process does provide order and consistency to projects. The intention is to ensure consistent results. The project team just follows the system cookbook and all comes out well.

The biggest problem with this approach is that all the process is, at its heart, intended to do is allow average quality staff to reliably deliver “acceptable” systems. And most of the time it delivers. Now, if all you want is an acceptable (read mediocre) system, then by all means go for it. For big process to work properly the project team should come onto the project already immersed in the company’s methodology based on actual prior experience with it. A very real problem with this approach in the government contracting world is that the development contractors do not keep stables of ready and willing people who have been deeply immersed in the company’s methodology on prior projects. When they win a contract they go out and hire mostly new people for the project, who then have to go through a long period of training and adjustment to the company’s methodology.

Big process tends to force big project size – and big project cost. Typically there exist separate sub-organizations for requirements management, systems engineering, software engineering, development, testing, configuration management, quality control, risk management, etc. And all of that process increases the amount of work (much of it administrative in nature), and also increases the communication load on the project. On a project with a smaller team, much can be done via informal channels where formal process would be needed in larger projects. Proper choice of support tools can improve productivity, and those tools come with built-in process. So using them gives you desirable best practice methodology without the need for separate formal written processes to deal with.

The primary uses for project documentation are (a) to allow the system to be developed and fielded, and (b) to support post-implementation system maintenance. I recommend limiting formal documentation to that which is truly needed. I believe a project needs a high quality set of formal system requirements, and a matching system test plan. Some level of design documentation is needed, with the higher level design being more important than the more detailed design. Depending on system complexity as well as security needs, other documents will be necessary. I believe it becomes a waste of money to continue to maintain anything but the highest level documents for purposes of system maintenance. Below a certain level of documentation needed for orientation purposes, maintenance people assume (largely correctly) that the documentation is out of date, and in any event they often prefer to just directly go to the code.

Exhibit Agility

Given that other conditions are extant, namely there is a small project; it is staffed with a solid leadership team; the project team is in a partnership mode with its customer; and the project is not overburdened with formal process, it becomes possible to take the final step to achieving the perfect project. The two most successful projects I have personally been involved in met these criteria, but also exhibited characteristics that now are associated with what is known as the Agile Methodology. The essence of “Agileness” is the ability to let things flow freely, and to operate intuitively versus slavishly following a rigid set of rules. It requires a high tolerance for ambiguity, and a willingness to quickly change direction, perhaps even radically. The team has to be fast on its feet.

Agility can be exhibited in any manner of ways. From the perspective of the project manager, that person may express agility in being able to rapidly shift assignments, based on knowledge of their subordinate team member’s individual experience and capabilities. This might be in response to a technical roadblock, a customer shift in priorities, or loss of a staff member. An individual analyst may need to multiplex multiple assignments, and be willing to instantly shift what they are doing based on project needs of the moment.

Agility also means thinking out of the box about how things are done. Consider system requirements. While I am a big believer in starting out with a solid set of formal requirements, one has to understand that those requirements are just an initial guess at what the system’s users truly need. It is right and proper to put together an early version of the system based on those requirements. But early pre-release user exposure will almost certainly identify various needs for adjustment. There may even be a need for significant rework. The agile team will, quickly and gracefully, make accommodation for them, even if major rework is needed. The users will deeply appreciate it. But at some point, typically after the first system release (but perhaps even earlier), it will make sense to just abandon those original requirements, and any attempt at traceability to them. The agile team then goes into change management mode and allows the system to morph into whatever it wants to become, as user complaints and suggestions for improvement pour in.

Not everyone is capable of what I used to call “go with the flow development”, and not every customer will allow it, but a project team that is able to operate intuitively can produce absolutely spectacular results.

John L. Dean is a seasoned IT professional with 40 years of varied experience, including systems engineering, systems analysis, requirements analysis, systems architecture and design, programming, quality assurance, testing, IV&V, and system acquisition, equally split between technical and management. He has worked both the contractor and government sides of the fence, has been an employee of large (IBM, CSC, Booz-Allen, MITRE, ACS) as well as very small companies, and is currently an independent consultant. He has a Masters degree in Operations Research from Clemson University. John is the “Project Whisperer”. His depth and breadth of experience gives him an unusual perspective on what does and does not work. If your project is running you, he can use his experience and intuition to diagnose why and apply calm, assertive energy to start corrective action, so you can and regain control! He can be contacted at [email protected].

Leaping Ahead in the New Year

Written by Cynthia Low on January 31, 2008. Posted in Articles. 1 Comment on Leaping Ahead in the New Year

We’re just into our second month of this Leap Year with our “once in four one day more” 29 day February and already we’re up to our necks in activity, getting each Business Analyst Times online, planning for the next one and organizing a year’s worth of Business Analyst Worlds.

We’ve managed to pull together a pretty good Business Analyst Times for the first week in February. John L. Dean continues his highly interesting and informative series, Road to the Perfect Project. This time out he takes a look at the importance of having a high quality set of senior analysts on any project. He also discusses how the PM and BA team can work effectively with the customer. Jim Swanson identifies the requirements phase as the point where business meets IT in his article, Writing Effective Project Requirements.

Our intrepid bloggers Terry Longo and Marcos Ferrer are back with their distinctive views on different aspects of our business. I’d also like to point you to our poll question from the last issue: we asked: Can the roles of Business Analyst and Project Manager be effectively combined? The results were: sometimes 45.8%; yes 32.2% and no 22.0%. Only 22% of you said categorically “no” while 78% felt they could be combined. Do you agree?

As usual, I hope you enjoy this issue and please give us some of your ideas for future issues. It’s the kind of input we need to keep our site truly relevant to you, our readers.

All the best.

Adam R. Kahn
Publisher
Ph: 508-309-6900
Email: [email protected]