The valley of death between IT and information security
http://bit.ly/9OXx06

Here is a summry:

Business Objectives are the measurable results a business desires to achieve when executing a project. They can be used to ensure that everything developed in the project contributes to the desired measurable business value. This discussion will help Business Analysts learn to develop good business objectives, to derive requirements from them, and how to apply them to control project scope.

University of Houston PMI Meeting

Wednesday August 18, 2010

5:30pm to 6:30pm

University Center, Bayou City Room (Room 202)

University of Houston
Houston Texas 77204-3038
http://www.uh.edu/campus_map/buildings/UC.php

(Parking available at the Welcome Center building or Hilton basement)This is a free event. For more information please visit: PMI Houston Event Page

Is the BA a Product Owner or Tester On Agile Projects?
http://bit.ly/dcmDfP

Is the CBAP® right for you?
http://bit.ly/94Bedy

Do You Know Where Your IT Projects Are? Part 1
http://bit.ly/a6rKFf

When good projects go bad
http://bit.ly/cngStn

1. Formal scripts – prepare formal scripts for the business users to run. If you can re-use any of QA’s scripts, all the better. At a minimum, use your use cases to build test scripts. As an added bonus, these scripts will serve as training to the business users on how to use the system after deployment. We suggest you have scripts for testing both functionally and migrated data.
2. Informal scripts – prepare informal, unstructured scripts for the business users to run as well. I strongly encourage you to do these in addition to formal scripts, in that these are the ones that will pull out defects about how the system isn’t intuitive to use. In addition, they may think to test things you didn’t formally script. As an example, this type of script might simply say “Login to the system and take a training course.” And you are hoping it’s intuitive to the user to figure out how to do that on their own.
3. Use a tool – we strongly encourage you to put your scripts in a tool and teach the business users how to use that tool. For example, Quality Center is a tool that works well for this.
4. Master data – create master data that can be used for testing by the business users. This includes logins and passwords and any data they must look at and/or consume in the tool. A great starting place to determine what data you need is to look at your Business Data Diagrams, and then of course look at your scripts. For example, if you have a training system, upload sample training courses for them to take during UAT. You should also organize this master data into a format such as a spreadsheet by test case, so they can quickly reference what data they should use in each script.
5. UAT Kick-off deck – Create a slide deck to kick the UAT window off with. This kick-off should include the scope of testing, a reminder about the value of the system, a reminder that it is a testing phase and they will find defects in the system, and instructions on how to perform UAT. You need to teach them about using the tools, how to login, and even where to go to access the system.
6. UAT User Manual – Create a manual for the users to quickly reference to while they execute the UAT scripts. You can hopefully reuse some or all of your kick-off slides. You definitely must include where to access the system (URLs), logins, and where to find master data.
7. Pre-run scripts – Ideally you should pre-run the scripts before the business users try to execute them. You are familiar with the system, so your eyes on the scripts will be looking for things that are not obvious or incorrect steps. This will help ensure a much more smoothly run UAT.
8. Teach them how to write a good defect – If you want to avoid a lot of manual labor yourself, teach the business users how to enter their own defects into a defect tracking system (and yes, I’m assuming you have one!). You need to teach them what information to include (logins, urls, steps to recreate) and how to set severity and priority values if appropriate.
9. Coordinate build schedule with dev – Make sure your dev team is onboard with your UAT testing schedule so that they don’t do a build while users are trying to test. And more importantly, if they do a build overnight, that they don’t take the system down with a broken build! In general you need to coordinate with your entire IT team, I just call this one out as they have an immediate way to cripple testing by accident.
10. Work with a business owner so they truly own acceptance – All of that said, you need to make sure there is someone in the business who owns the UAT process. You are simply here to facilitate it going well and do a lot of the prep work for them. But truly, they must be the ones who own acceptance of the system or they will never actually adapt it for use. So every step of the way as you go through your prep tasks, be sure you are getting the business UAT owner’s buy-in!

And a bonus #11: Have fun with it! This is when you get to see your system come to life with the people who will be use it. If you have fun, they’ll be more likely to have fun and actually enjoy this!!

Negotiating for Specifications and Resources on the Project
http://bit.ly/9KBuVp

What Do Business Analysts Actually Do for Software Implementation Projects?
http://bit.ly/BJXzc

Tips for BAs: Increasing Productivity and Performance
http://bit.ly/cQ7va7