Determine Business Objectives:

    1.    Why do you want to redo the system?

    2.    How will the new version of the system help you?

    3.    What are your objectives in having this system?

    4.    Who are the key stakeholders and users? Do their goals differ? If so, how?

    5.    How does the system map to business goals?

    6.    What is the most important business goal of the system?

    7.    Will the system change the way you are doing things now?

    8.    Will the system help you be more efficient?   How?

    9.    What are the system deliverables? 

   10.   What will the converted system accomplish that the current system cannot    accomplish?

   11.   Will the output of the converted system be the same or different than the      current system?

   12.   Will the new system have additional functionality?    What?

   13.   Will the new system have better performance?    To what extent?

   14.   Will the new system help you be more efficient?    To what extent?

   15.   Will the screens look different?  How?

   16.   What is most important (rank in order of importance): 

                  Application is easier to use

                  Application has nicer front-end

                  Application has additional functionality (list)

                  Application is more efficient

                  Application is redesigned to better reflect the business

Determine Future Needs

   1.    What business requirements will this system address?

2.        Is the data and/or functionality shared by other (many) business areas?  If so, which?

3.        If the reports were dynamic, what would they do differently?

4.        How much historical information is required?

Determine Current Problems

   1.    What are the current problems with your system today?

   2.    Do you have to do things manually that you would like to automate?

   3.    Do you have performance problems that need to change?

   4.    Do you have functional limitations that you’d like to change?

5.        What is the risk of not converting the system?

6.        Which reports do you currently use?  What data on the report is important?  How do you use the information?

7.        Are there specific bottlenecks to getting at information?

8.        How do you analyze the information you currently receive?  What type of data is used?  How do you currently get the data?  How often do you get new data?

9.        What type of ad hoc analysis do you typically perform?  Who requests ad hoc information?  What do you do with the information?

Determine System Users

   1.    Who will be using the system?

   2.    What are the titles and roles of the people who will use the system?

3.        What are their levels of expertise?

Determine Criteria for Success

    1.    What do we need to accomplish to make this project successful?

    2.    What do we need to change to make this project successful?

    3.    What buy-in do we need?

    4.    Are we lacking any critical elements such as budget, resource allocation, or    support?

    5.    What are the training considerations for developers and users?

System Research

    1.    Who are the most important players in terms of – Knowledge  - Politics?

    2.    Is there any existing system documentation?  If so, where?

    3.    Who else should we talk to?

Assumptions and Issues

    1.    List assumptions

    2.    List open issues, responsible parties, resolution date

Information from this questionnaire should be used to develop the detailed business requirements in the Project Requirements document.  Ask these questions for each high- level business process to identify the detailed business processes, associated functionality, functional and reporting deliverables.

§         Determine High-Level Functions

    1.    What will the process do that you are doing manually now?

    2.    If using purchased packages, what do they do?

    3.    What will this process/function do that is entirely new?

    4.    Are there related processes/functions within the scope of this process?    (list these)

    5.    How do these processes/functions interact with each other?

    6.    What is the level of complexity of each process/function?

    7.    Are there other systems/projects that must interface?  (What are they?)

    8.    What is the functional core of this process?

    9.    What are the priorities for this process?

Determine Development, Deployment, Usage Constraints

    1.    Are there time constraints in developing the process/function?  What are they?

    2.    Are there time constraints in deploying the process/function?  What are they?

    3.    Are there any dependencies on other systems in completing the system?   Please specify.

    4.    Are there budget constraints in developing this process/function?   How much?

    5.    Are there resource constraints in developing the process/function? (in-house expertise available)?

    6.    Do we have management and user commitment and buy-in?

7.        Are there technical constraints to developing this process/function? What are they?

8.        Is there remote processing?  Are there scheduler constraints to consider (CA7 and/or CA7 Agent)?

§         System Research

    1.    Who are the most important players in terms of:

                - Knowledge

                - Politics

    2.    Is there any existing system documentation?  If so, where?

    3.    Who else should we talk to?

§         Assumptions

    1.    List assumptions

§         Issues/Risks

1.        List open issues, responsible parties, resolution date

Inclusions -   List inclusions

§         Exclusions – List exclusions

Information from this questionnaire can be used to develop high level business requirements.

Determine Business Objectives

    1.    What are your goals in developing this system?

    2.    Who are the key stakeholders and users? Do their goals differ? If so, how?

    3.    How do the system goals map to business goals?

    4.    What is the most important business goal of the system?

    5.    Will the system change the way you are doing things now?

    6.    Will the system help you be more efficient?  How?

    7.    What are the system deliverables? 

    8.    What will the new system accomplish that is not currently accomplished manually or with other systems?

    9.    What will the new system do?

Determine Future Needs

    1.    What business requirements will this system address?

    2.    What information do you need from this system that you don’t have now? 

    3.    Is any of this data currently captured in any other corporate system?

    4.    How would you like to see this information?  

    5.    What functionality do you need from the system?

6.        Is the data and/or functionality shared by other (many) business areas?  If so, which?

7.        If the reports were dynamic, what would they do differently?

8.        How much historical information is required?

Determine Current Problems

    1.    What are the current problems facing without the system today?

    2.    What problems should this system solve?

    3.    Do you have to do things manually that you would like to automate?

    4.    Do you have performance problems that need to change?

    5.    Do you have functional limitations that you’d like to change?

6.        Are you using packages that force you to constrain your business functionality to the boundaries of the package?

7.        Which reports do you currently use?  What data on the report is important?  How do you use the information?

8.        Are there specific bottlenecks to getting at information?

9.        How do you analyze the information you currently receive?  What type of data is used?  How do you currently get the data?  How often do you get new data?

10.    What type of ad hoc analysis do you typically perform?  Who requests ad hoc information?  What do you do with the information?

Determine System Users

   1.    Who will be using the system?

   2.    What are the titles and roles of the people who will use the system?

   3.    What are their levels of expertise?

Determine Criteria for Success

   1.    What is most important for success of the application?

   2.    What do we need to accomplish to make this project successful?

   3.    What do we need to change to make this project successful?

   4.    What buy-in do we need?

   5.    Are we lacking any critical elements such as budget, resource allocation, or support?

   6.    What are training considerations for developers and users?

Assumptions

    1.    List assumptions

Issues

    1.    List open issues, responsible parties and resolution date

3 Step Method

This is a good technique for identifying risks and issues.  Use this technique for the beginning of the session.

1.                  Individual- Write ideas and thoughts on flip chart paper/whiteboard.  Be creative and draw pictures.

2.                  Small Group- Break up into groups of 3 – 5 people.  Each person in the group should present their results.  As you listen to the presentation note the common themes.  Each group creates a consolidated group list.  Each group presents their results and gets feedback from the larger group.

3.                  Large Group- Facilitator leads the group and consolidates decisions from each group getting consensus for the final lists.

Business Analysts are responsible for facilitating requirements analysis, requirements validation and business process improvement.  Below are some qualities and traits of a good Requirements Lead and Business Process Improvement Facilitator that a Business Analyst should develop to be effective.

·        Communicates well

·        Processes ideas from people

·        Shows a natural interest

·        Listens well

·        Maintains control

·        Empowers the group

·        Handles uncertainty

·        Is quick to connect with the group

·        Focuses on the business not their own solutions

·        Communication skills

§         Negotiating

§         Group dynamics

§         Listen/draw conclusions

·        Business Savvy

§         Running meetings

§         Systems Analysis & Design

§         Relates well to people

·        Management skills

§         Project Management

§         Manages people’s expectations

·        Reputation

·        Impartial

·        Devoted to the process

§         Understands and constantly sells the process

Pierson Requirements Group provides training in effectively leading requirements and business process improvement initiatives.  Some popular classes for improving the Business Analyst facilitation skills are the Business Requirements Gathering & Writing Seminar using JAD, Use Cases and UML Techniques and the Business Process Management Facilitation.   

To learn more about training that is available for these collaborative techniques and methodologies click on Pierson’s Requirements Group’s agendas for JAD Facilitation & Requirements Gathering using Use Cases and Business Requirements Gathering & Writing Seminars.

3 Step Method

This is a good technique for identifying risks and issues.  Use this technique for the beginning of the session.

1.                 Individual- Write ideas and thoughts on flip chart paper/whiteboard.  Be creative and draw pictures.

2.                 Small Group- Break up into groups of 3 – 5 people.  Each person in the group should present their results.  As you listen to the presentation note the common themes.  Each group creates a consolidated group list.  Each group presents their results and gets feedback from the larger group.

3.                 Large Group- Facilitator leads the group and consolidates decisions from each group getting consensus for the final lists.

Presentation and selling of the process change

Communication of the process change to management and the staff is key to a successful transition.  The team would create the presentation to sell the process change to everyone.  Determine what will be in the presentation and how it will be presented.  The case for the management presentation should include the following:

1. Where are we now? (present the previous current state)
2. What does this mean to us?
3. Where do we want to be? (present the new state)
4. What are the benefits?
5. Why these benefits?
6. Identify the options for the actions
7. How will you evaluate the solution?  How will you measure the success?
8. State the recommendations for change
9. Identify the next steps

Sample Presentation Agenda:

·         Introduction

·         Review the “Previous Current State” (storyboard)

·         Present the Business Statement of Intent

·         Present the “New Current State” Process (storyboard)

·         Present the “Action Plan” with benefits

·         Closing and next steps

Pierson Requirements Group (www.PiersonRequirementsGroup.com) offers business analysis training to companies seeking a more efficient approach to software development.

Stamford, CT – March 18, 2009 – Companies no longer have to suffer poor return on investments (ROI), or accept costly redesign efforts as the norm in software development. Business analysis training and JAD training classes from Pierson Requirements Group help members of management and staff work together to avoid the most common pitfalls in requirements planning to maximize efficiency and ROI.

“The problems most companies have with software development are due to poor requirements rather than coding,” says Pierson Requirements Group Partner, Joy Matthews. “Developers know how to code but the business requirements are most often incomplete and don’t effectively communicate the business needs. The lack of effective requirements gathering and writing leads to 82% of the software re-design and maintenance efforts causing companies to waste millions of dollars a year on ineffective software implementations and lost product to market opportunities. [Our] customers have found that it is a 200:1 cost savings to find defects in requirements rather than in the maintenance phase.”

Pierson provides hands-on training in requirements gathering and writing, testing, and project management with an interactive approach. The business analyst training classes are designed to improve project performance by teaching project teams how to work together to implement industry standards and best practices.

The methodology is so effective that customers of Pierson Requirements Group have reported that $12,000 – $15,000 business analyst training classes have produced a $144,000 to $192,000 ROI in a year. According to Matthews, “Surveys of Pierson’s customers have found that the use of a Collaborative Requirements Approach saved 25% to 33% of time over the entire project, or three to four months out of a year-long project.”

Pierson offers training classes or seminars in business requirements analysis, UML and business modeling, QA testing, project management, requirements gathering and writing, JAD facilitation and requirements gathering, and more. The company also offers mentoring and consulting services for more direct involvement in clients’ software development projects.

About Pierson Requirements Group

Pierson is an Endorsed Education Provider of the IIBA- International Institute of Business Analysts and a member of the BABOK review board.  All of Pierson’s courses can earn PDUs with the Project Management Institute (PMI) and CDUs with the IIBA.

Pierson Requirements Group has been the leader in requirements training and testing training using industry best practices for 18 years and is often recommended by Gartner to its clients. What makes Pierson’s training unique and successful is that the training classes conclude with a simulation using the deliverables throughout the PLC.  A real life customer’s project can even be used. The training is 1/3 lecture and 2/3 hands on exercises so that the trainees are ready to go after completing the class and equipped for success with a full toolkit of checklists, a procedures guide, agendas and scripts. The primary objective of the training is to provide the participants with the knowledge and experience to implement a repeatable requirements gathering and writing process using UML and helps prepare those who want to take the IIBA Certification Exam.  Participants of Pierson’s training are provided with a certificate of successful completion of the training.

For more information about Pierson Requirements Group or business analysis training, please visit www.PiersonRequirementsGroup.com or contact Walter Pierson at 203-322-1606.

Contact:
Walter Pierson, President
Pierson Requirements Group
Phone: 203-322-1606
Email: wpierson@piersonrequirementsgroup.com
Web: www.PiersonRequirementsGroup.com

Pierson Requirements Group’s customers have found that they are able to capture 93 – 95% of the business requirements functionality by using a collaborative requirements method and by creating and validating paper prototypes with the business community.  Pierson’s philosophy is to strive for consensus based requirements in order to provide better customer satisfaction.  If a more traditional interviewing approach is used to gather requirements, studies show that only 65% of the requirements will be captured.  When using a collaborative approach to gathering requirements Pierson’s studies show that there will be at least 90% of the business requirements defined.  If companies validate the data descriptions and the screens and reports, the requirements will be further defined to the programmer and a better understanding of the business and technical community is achieved.  JAD session and focus groups are both excellent tools for implementing a collaborative requirements gathering approach.

To learn more about training that is available for these collaborative techniques and methodologies click on Pierson’s Requirements Group’s agendas for JAD Facilitation & Requirements Gathering using Use Cases and Business Requirements Gathering & Writing Seminars.