Life and Spiritual Coaching

September 29, 2008


Filed under: Life Balance,Successful — by Donna Ritter @ 4:54 pm
Tags: ,

Just as I have told you to keep a gratitude journal, keep a success one too. When I was working at one point, if someone ever sent me a thank you note or a good job note, I’d file it under my Kudos file. If I ever felt bad, I’d pull out my Kudos file to bring me back up again.

Many people don’t realize how many successes they’ve had in their lives. Try writing them down in a list for days when you don’t feel so great. I try also to surround myself with other people who are successful, passionate and can teach me something. We all can learn from one another. Successes should be celebrated. As humans, we tend to remember the bad things because they bring up so much emotion. Even celebrate your failures – they are wonderful learning tools. The more risks you are willing to take, the better your self esteem will be.

One thing I have noticed is I cannot stay around toxic people. You know the type. They complain about their spouse, their kids, their jobs and blame it all on something else. If you stay around people like this, they will drag you down so fast you won’t know what hit you. I don’t mean you should ignore a friend who is in trouble, but stay away from the constant naysayers.

You are a unique individual. There is no one else like you or who have your talents! Don’t ever forget that and keep thinking positively and surrounding yourself with others who you can learn from. Also, volunteering is a wonderful way to boost your self-esteem.


God and I love you! Donna

September 28, 2008

Using Mind Mapping to Help Your Thought Process

Filed under: Tools — by Donna Ritter @ 1:02 pm


Mind Mapping, an idea put forth by Tony Buzan, is a useful technique especially if you work best by picturing things in your mind. It starts by writing in the middle of the page, the core concept you are defining. Your mind maps are highly individual and creative, reflecting your inner most thoughts.


From the center core idea (like losing weight, designing a software program, any concept you need to figure out how to do), draw lines with supporting concepts radiating from the center. Try to use key terms that will trigger other thoughts. Express each thought in 3 or less words. You can also branch off the ideas radiating from the center.


Include whatever you find appropriate; pictures, cartoons, images, symbols or words.


Ideally add colors that mean something to you about that particular idea. In a very small amount of time you will find that you have multiple ideas to solve your problem!


Two of the best books on Mind Mapping explain this in much more detail. They are the Mind Map Book by Tony Buzan and Mapping Inner Space by Nancy Margulies.


You mind holds a tremendous amount of information that can be tapped into using this technique. I’ve used it often to solve software problems and to give me ideas on how I want to design a training course.


Have fun with it! You will be pleased with the results.

September 27, 2008

9 Ways to Live a Christian Life

Filed under: Christian — by Donna Ritter @ 5:22 pm

What does leading a Christian Life mean to you? To me, these are the 9 essential Christian ways I live my life.

1.   Always forgive. It doesn’t matter how bad the offense is. God forgives us sinners and totally wipes our sins away. Can any of us say we deserve this unconditional forgiveness? If you have a problem forgiving someone, pray to the Lord to fill you with the Holy Spirit to enable you to forgive.

2.   Treat all people with kindness. None of us know what God’s agenda for another person. We have no right to judge others. That right belongs to God himself.

3.   Read the Bible every day and perceive what the Holy Spirit is telling you. I know in my own studies I can read the same passage at different times in my life and get a different message. God knows what we are going through and gives you the message you need at that time. The bible is a living document that gives you the messages you need at the time of your life even though you had already read it before. That is the reason you must read it every day. And remember that Jesus was the Word.

4.   Start your day out by reading inspirational thoughts and have quiet time before you here of the bad news in the world. This will allow you to start fresh and be at peace.

5.   Witness to those who do not have the Lord in their heart. We were called to lead others to Christ. Teach your children about God. Let them know they will be saved.

6.   Keep the Holy Spirit in your heart. Jesus gave us the Holy Spirit when he ascended to heaven. We all sin and when that happens pray to the Holy Spirit even if you don’t know what to ask. He will save you.

7.   Pray, Pray, Pray. At night pray that you will follow his teachings. And always give thanks for His abundance.

8.   Believe in the Salvation of Jesus. Believe in His Grace.

9.   We are the temple of the Holy Spirit. Act like it.


September 26, 2008

Dealing with Difficult People

Filed under: Life Balance — by Donna Ritter @ 2:07 pm
Tags: ,

I am sure that many of you have had to deal with difficult people in their lives. Who hasn’t? Here are my top 9 ways of dealing with a difficult person:

1.   Learn how they like to be communicated to. We all have different styles and if you use the style they prefer you may have some success.

2.   Take a long walk and clear your head before any communication takes place. Be at peace.

3.   Read some scriptures. I have found these to be handy:

a.   You can pray these for yourself, even memorize them and recite them to yourself before you speak with the person so that it will be on your mind when you need it most.
Proverbs 14:1
The wise woman builds her house, but the foolish tears it down with her own hands. (Pray you will build up your home not tear it down- I pray this often.)

b.   Proverbs 15:1
 A gentle answer turns away wrath, but a harsh word stirs up anger. (Pray God will give you a soft answer when they are harsh.)

c.   Ezekiel 36:26
“Moreover, I will give you a new heart and put a new spirit within you; and I will remove the heart of stone from your flesh and give you a heart of flesh.


4.   Leave some time before you have to communicate if you are stressed about it.

5.   Try to find some common ground.

6.   Tell the person to their face that you are having a hard time and ask if they can help you to understand them more.

7.   Start with talking about something you admire about the person. This will give them a good feeling.

8.   Eat some chocolate (or whatever makes you feel good) before your conversation.

9.   Offer some chocolate to the person before you converse.


September 23, 2008

Finding Yourself In this World

Filed under: Life Coaching — by Donna Ritter @ 6:39 pm

I was brought up to be an independent woman and to expect that I should do something that would take care of any costs I may have in my life. Well, it turns out that life doesn’t always turn out like you want. I recently have had a problem with degenerative disc disease so commuting 1-2 hours a day is not an option for me anymore. I’m sure for every person you talk to, God has thrown them a “Lesson” to help us to understand that we shouldn’t rely on material goods – but on Him.

As usual, He did know what was better for me than I did. I took a lot of assessment tests and found that I have not really been in the right career for my personality. I am more of a mentor, teacher, and coach than a technical corporate engineering manager.

So, I have studied with Franklin Covey Coaching along with a number of other coaching disciplines to learn  methods of coaching. I have also engaged several of my other coaching friends and am ready to take on the world! Or am I?

Now there are two types of people in the world – those that think they know it all and those that ask for help when they need it. I am the type of person that constantly spends time learning, and while doing that I realize what parts of a job I like and do well, and what parts I don’t like and can get someone else to do.

Everyone needs a support system. It doesn’t matter what business you are in. There are some things that others do better than you can so why bang your head against the wall! Spend your time on what you do best and do what you do best!


September 21, 2008

More on Ike

Filed under: Hurricane — by Donna Ritter @ 1:12 am

In the newspaper today, many areas around here are not going to get electricity until October! Stores are barely stocked and some areas have houses that are ruined. We were so blessed. The people across the street won’t have electricity until Thursday.

It takes a disaster like this to make you realize how blessed you are. I am sure lots of you have seen the pictures of devastation. Some folks have lined up since 3am to receive food stamps only to find out in the mid-afternoon that they are not eligible.

Join me in saying a prayer for those less fortunate than others. Less than half of the folks have electricity and water has to be boiled for food.

I grew up in New Orleans and I never in 12 years in Houston have seen it so bad. Schools are closed for 2 weeks. I am volunteering to help others less fortunate than my family and urge you all to do the same or send money to help with the relief effort.

September 19, 2008

Earned Value and It’s Tecnquices

Filed under: Uncategorized — by Donna Ritter @ 6:02 pm
Tags: , , , ,


I have used these teniques for years. They are very poweful and can answer the questions Project Management must ask.And for those going after a PMP certifiction expect a lot of these quetions!

Interpretations of various Earned Value Calculations

Questions every Project Manager Must Ask:

Schedule Variance (Are we ahead or behind schedule?)


·         The Schedule Variance (SV) determines whether a project is ahead of or behind schedule. It is calculated by subtracting the Planned Value (PV) from the Earned Value (EV). A positive value indicates a favorable condition and a negative value indicates an unfavorable condition. For Project EZ: SV _ EV _ PV _ 32 _ 48 _ _16 {unfavorable}

·         The Schedule Variance can be expressed as a percentage by dividing the Schedule Variance (SV) by the Planned Value (PV):

SV% _ SV / PV__16 / 48 _ _33% {unfavorable}


In other words, the project is 33 percent behind schedule, meaning that 33 percent of the planned work has not been accomplished.


Schedule Performance Index (How efficiently are we using time?)


·         The Schedule Performance Index (SPI) indicates how efficiently the project team is using its time. SPI is calculated by dividing the Earned Value (EV) by the Planned Value (PV). For Project EZ:

SPI _ EV / PV _ 32 / 48 _ 0.67 {unfavorable} bad

·         This Schedule Performance Index indicates that—on average—for each 8-hour day worked on the project, only 5 hours and 20 minutes worth of the planned work is being performed; that is, work is being accomplished at 67 percent efficiency.


Time Estimate at Completion (When are we likely to finish work?)


·         Using the Schedule Performance Index (SPI) and the average Planned Value (PV) per unit of time, the project team can generate a rough estimate of when the project will be completed, if current trends continue, compared to when it was originally supposed to be completed (see Box 3-1). For Project EZ: EACt (BAC/SPI)/(BAC/months) _ (150/0.6667)/(150/12) _ 18 months


The originally estimated completion time for the project was 12 months, so the project manager now knows that if work continues at the current rate the project will take six months longer than originally planned. It is important to note that this method generates a fairly rough estimate and must always be compared with the status reflected by a time-based schedule method such as critical path method. It is possible that an Earned value analysis could show no schedule variance and yet the project is still behind schedule; for example, when tasks that are planned to be completed in the future are performed ahead of tasks on the critical path.


Cost Variance (Are we under or over our budget?)


A project’s Cost Variance (CV) shows whether a project is under or over budget. This measure is determined by subtracting the Actual Cost (AC) from the Earned Value (EV). The CV for the Project EZ example shows:

CV _ EV _ AC _ 32 _ 40 _ _8 {unfavorable}

This number can be expressed as a percentage by dividing the Cost Variance (CV) by the Earned Value (EV).

CV% _ CV / EV__8 / 32 _ _25% {unfavorable}


In other words, to date, the project is 25 percent over budget for the work performed.

Cost Performance Index (How efficiently are we using our resources?)

Earned Value and Actual Cost can also be used to calculate the cumulative Cost Performance Index (CPI), which is one of the clearest indicators of the cumulative cost efficiency of a project. CPI gauges how efficiently the team is using its resources.


It is determined by dividing the Earned Value (EV) by the Actual Cost (AC). In regards to Project EZ, the CPI is:

CPI _ EV / AC _ 32 / 40 _ 0.80 _ 0.80 {unfavorable}


Translated into dollars, this means that Project EZ has a cost efficiency that provides US $0.80 worth of work for every project dollar spent to date.


To-Complete Performance Index (How efficiently must we use our remaining



Another very useful index is the To-Complete Performance Index (TCPI), which helps the team determine the efficiency that must be achieved on the remaining work for a project to meet a specified endpoint, such as the Budget at Completion (BAC) or the team’s revised Estimate at Completion (EAC) (see the following discussions of EAC and ETC). The TCPI for achieving the BAC is calculated by dividing the work remaining by the budget remaining as follows:


TCPI _ (BAC _ EV) / (BAC _ AC) _ (150 _ 32) / (150 _ 40) _ 1.07


This means that for Project EZ to achieve the BAC, performance must improve from a CPI of 0.80 to a TCPI of 1.07 for performance of the remaining work.


Estimate at Completion (What is the project likely to cost?)


The calculated Estimate at Completion (EAC) projects for the team the final cost of the project if current performance trends continue. One common method for calculating the EAC is to divide the Budget at Completion (BAC) by the cumulative Cost Performance Index (CPI). For Project EZ, this is: EAC _ BAC / CPI _ 150 / 0.80 _ 187.50


This forecasting formula assumes that the cumulative performance reflected in the CPI is likely to continue for the duration of the project. Other formulas used to forecast cost at completion with earned value data are outlined in Box 3-2. Estimates based on project team and management analysis of remaining work are discussed in the following section on Estimate to Complete (ETC).


Variance at Completion (Will we be under or over budget?)


With the EAC figure in hand, the manager can now compute the cost Variance at Completion (VAC), which shows the team whether the project will finish under or over budget, by subtracting the EAC from the BAC. For Project EZ, this is: VAC _ BAC _ EAC _ 150 _ 187.50 _ _37.50 In other words, if current trends continue, the project will cost an additional 37.50 units worth of resources than originally planned. This can be expressed as a percentage by dividing VAC by BAC.

VAC% _ VAC / BAC__37.50 / 150 _ _25%


Estimate to Complete (What will the remaining work cost?)


There are two ways to develop the Estimate to Complete (ETC), which shows what the remaining work will cost. One way is a management ETC developed by workers and/or managers based on an analysis of the remaining work. The management ETC can be added to the Actual Cost (AC) to derive the management Estimate at Completion (EAC) of the total cost of the project at completion. EAC _ AC _ ETC _ 40  


As a check on these management estimates, organizations can use a calculated ETC based on the efficiency-to-date measured by the CPI. The calculated ETC can be used to determine the calculated Estimate at Completion (EAC), which the team can compare with the management EAC. For Project EZ, the ETC and EAC are calculated as follows:

ETC _ (BAC _ EV) / CPI _ (150 _ 32) / 0.80 _ 147.50

EAC _ AC _ ETC _ 40  147.50 _ 187.50

Note that this EAC formula is equivalent to the following (see Box 3-2):

EAC _ AC _ [(BAC _ EV) / CPI] _ BAC / CPI


Management by Exception

EVM provides an organization with the capability of practicing ‘‘management-by exception’’ on its projects. This practice contributes greatly to the efficiency and effectiveness of project management, by allowing managers and others to focus on project execution and invoke control actions only when and where they are needed. EVM performance measures, used in conjunction with the project work breakdown structure (WBS), provide the objective data needed to practice ‘‘management-by exception.’’


Using EVM, an organization can establish acceptable levels of performance for a project and its work tasks. Variance percentages and efficiency indices are most often used. For instance, an organization may consider a Cost Variance (CV) of plus or minus 10 percent to be an acceptable range of variance from the project management plan. In this case, no management action would be taken except when and where a CV falls outside of this acceptable range. While a negative variance is potentially problematic, a positive variance may represent an opportunity.


Because EVM occurs first at the task level, where the scope, schedule, and cost of work are planned and controlled, the ‘‘management-by-exception’’ also starts at this level. Managers use EVM performance measures to determine whether action thresholds have been reached for their tasks and control accounts. And with the use of a work breakdown structure, which ties the tasks and control accounts of a project together, EVM and ‘‘management-by-exception’’ can be used at any level of the project (specified in the WBS).


While variance and efficiency thresholds are commonly used in EVM, trends in the performance measures for a project can help a project manager decipher or anticipate a potential performance problem. For instance, a cumulative Cost Performance Index (CPI) that is within an acceptable range, but has been trending down toward the efficiency threshold for several measurement periods, may be cause for some concern and prompt an examination of the underlying cause of the trend. If the trend is seen at the project level, a WBS will enable the manager to ’’drill down’’ to lower levels to see what underlies the trend.


Graphs of variance and efficiency data are helpful tools in performing this kind of Earned Value analysis. Plotting the CV percentage or the CPI over time, for example, will indicate their values and show their trends. Computer software, especially some developed specifically for project management and EVM, is capable of producing such graphs. Box 3-3 outlines other basic kinds of performance management and reporting displays that are frequently used in EVM. Appendix E provides additional sources of information on EVM concepts, methods, and practices.









September 17, 2008

SimplifyYour Life

Filed under: Life Coaching — by Donna Ritter @ 12:48 pm
Tags: ,

As I said in an earlier post, we all have too many things to do each day and we need ways to focus our energy on the most important things in our lives. Here is a list of things to think about when you find yourself in a state of panic from all of the things people are asking you to do:

  • Do nothing. See you’re so task oriented that you automatically wanted a list of things to add to your to-do list. Take some time to do nothing, just sit there and be with yourself. It’s so hard for most people that being left to do nothing is a severe form of torture.
  • Throw something out. Look into a drawer that you haven’t opened in awhile and pick an item to throw out based on the fact that you know you won’t use it again. We are natural hoarders, but this just adds unnecessary complexity to our lives.
  • Clean your desktop. Sitting at a desk with no clutter will keep our minds clear and thinking about the task at hand. Start becoming distraction free in the seat you spend most of your day in.
  • Clean your desktop, again. This time I’m talking about the one on your computer. Get rid of all those icons and organize the folders in which you keep all your programs. Give yourself something visually simple to look at in order to keep a clear and focused mind.
  • Make your bed. Many of us don’t make our bed the first thing after we get up. Sometimes this gets neglected completely, unless we’re expecting company. Make it first thing and look forward to climbing into something neat and comfy at the end of the day.
  • Clear your inbox. I love e-mail’s archive feature, it allows you put things away, and keep your inbox clean. Reply to everything you need to, delete everything else, and keep your e-mail as a focus point, not a clutter point.
  • Eat slowly. Do not treat eating as one of life’s little inconveniences. Instead, eat slowly and enjoy each bite as if it were your last, and if it were, know that you got the most out of it.
  • Drive slower. There’s no need to speed race, talk on your cell phone, eat, and take notes all at the same time. Treat driving time as a time for decompression, meditation, and de-cluttering of your mind. Turn off the cell and enjoy these quiet moments of solitude.
  • Laugh out loud. You really can trick your body into being happy by laughing out loud. If you don’t believe me, I’ll make a believer out of you. Spend the next 3 minutes laughing out loud, as hard as you can, making the sounds and body motions. You will be happier.
  • Talk to people. Instead of being absorbed in newspapers and television shows find a person to talk to. Discuss goals, dreams, aspirations and none of that self-pitying or past tense thinking.
  • Pick most important things. Sit down with pen and paper and decide on the 3 things that are most important in your life, and how you can drop everything else to achieve them.
  • Drink water. Forget the sophisticated and often complicated drinks and stick to the most essential of all — water. At least 8 cups of this stuff a day — a bit less if you eat a lot of fruit — and a bit more if you exercise or sweat heavily.
  • Go for a walk. You don’t even have to put on your fancy bubble sneakers and hit the treadmill. It’s enough to go for a nice walk — at least 30 minutes (yes, that’s 2x 15, you’ll thank me for it one day) — and let some blood pump through your body. It’s recommend to do this 3 times a week to stay healthy, but my personal recommendation would be to make this into your daily routine.
  • Clean your closet. Do your laundry, put away all your clothes, and then take a good look at your closet. What do you not wear? What is not essential? Put the answers to these questions in a box and donate them.
  • Plan your meals. Eliminate the guess work of where will you eat next by planning, if not the whole week, than at least this entire day, as far as what and where you will eat. I guarantee that planning will allow you to make healthier choices while going easier on your wallet at the same time.

o   “Nature is what we know – Yet have not art to say – So impotent our wisdom is To her simplicity”
~Emily Dickinson

  • Visit nature. Bask in the beauty and serenity that nature has selflessly provided us with. Go to a forest, park, or simply sit under a tree, and do nothing, read a book, or chat with a friend. While out walking I saw a kid sitting under a tree with his laptop; while not the most effective use of nature, it still beats doing the required homework inside the house on a beautiful day.
  • Play catch. You won’t find too many activities easier than tossing the ball around between two people. It’s great exercise, it’s relaxing yet invigorating, and a great opportunity to talk and bond.
  • Eliminate distractions. Whether you’re working, reading, doing homework, or spending time with someone it’s important to give it your full attention. Turn off the phone, television, and any other distractions that can pop up unannounced. Be present.
  • Say ‘No’. In an effort to simplify, do not accept new commitments that you don’t want to accept. Say no to your boss, spouse, kids, and friends. Explain to them that you need some time to concentrate on the tasks at hand in order to simplify your life and increase your happiness, productivity, and vitality.
  • Read daily. If you were to take out 30 minutes a day to read (another 2×15), you will have spent 4.5 full work weeks reading by the end of the year. You would be very smart.


September 16, 2008

PM and BA Glossary

Filed under: Business Analyst,PMP,Project Manager — by Donna Ritter @ 7:19 pm

3-Pass approach: method of finding the critical path by working through calculations on the network three times: forward; backward; and once again to calculate the activity and network flexibility (float).


Acceptance: one of four possible strategies for response planning with regards to an identified risk; indicates the impact of the risk that can be tolerated at its identified level.

Active/visible observation: observing in a way that interacts with those being observed (i.e., asking questions and having others describe what they are doing and why).

Activity: component of work performed during the course of a project; also called a task.

Activity diagram: dynamic modeling technique used to show activities and decision points, and the roles assigned to them.

Administrative closure: the activities of the project team necessary to collect project records, analyze project success or failure, gather lessons learned, and archive project information for future use; performed when a project ends, when a project is terminated before work is complete, or at the end of each project phase.

Administrative closure process: includes perform product verification, complete final project performance reporting, obtain formal acceptance of project, perform lessons learned, create project archives, release resources, and celebrate!

Application architect: responsible for reviewing the requirements for feasibility and using them as a guide in developing the system architecture.

Application architecture: part of the enterprise architecture that shows how the various software applications interact.

Assumptions: things considered real, true, and certain for the purposes of planning; factor believed to be true but not confirmable or factor known to be true but that could change during the project.

Avoidance/elimination: one of four possible strategies for response planning with regard to an identified risk; indicates that risk cannot be tolerated to any degree and must be prevented from having any impact on the project.


BABOK: Abbreviation for IIBA’s Business Analysis Body Of Knowledge.

Backward pass: method of determining the late start time (LST) and late finish time (LFT) for each activity.

Baseline: project’s point of reference for requirements changes; established at the point of plan approval and should not be changed except in response to significant, approved change in the project scope.

Black box reverse engineering: deduces the system’s requirements from its behavior, without examining its code or other technical details.

BOSSCARD Framework: acronym for remembering project definition elements: Background; Objectives; Scope; Stakeholders; Constraints; Assumptions; Reporting; and Deliverables.

Brainstorming: requirement elicitation method that generates creative ideas among a group of people; success is dependent on participants’ creativity.

Business Analyst (BA): a person who identifies the business needs of clients and stakeholders to determine solutions to problems; responsible for requirements development and management; acts as a bridge between the client, stakeholders, and the solution team.

Business architecture: part of the enterprise architecture that shows the structure of the enterprise (that is, divisions, locations, etc.) and its product or service strategy.

Business constraints: limitations imposed on the solution related to business activities, (i.e., budget limitations); restrictions on the people who can do the work (skill sets available, etc.).

Business objective: defines why the project is important to the business and what the business needs to get from the project for the investment to be successful.

Business requirement: stated from the viewpoint of the business function and using that terminology.

Business risk: eventualities that could threaten the project; positive (opportunities) or negative impacts the project could have on the business.

Business rules: static modeling technique that looks at the rules governing business processes and decisions (regulation, company policy, etc.).


CAPM®: Certified Associate Project Manager; certification offered by PMI; requires less experience than PMP®.

Capability: the functionality of the specified system.

Cause-and-effect diagram: combines brainstorming and concept mapping to identify and consider a range of causes and impacts relative to a problem; also referred to as a fishbone diagram or an Ishikawa diagram.

CBAP: Certified Business Analysis Professional; certification offered by IIBA.

Class model: static modeling technique that looks at representations of each entity in a system, showing the attributes and activities of each; describes one or more objects with a uniform set of attributes and services, including a description of how to create new objects in the class.

Closed-ended surveys: survey method that limits the responders’ options to pre-selected choices; requires writing questions with great skill and care to avoid ambiguity or bias; provides quantitative data.

Communications Management: one of nine Knowledge Areas identified in the PMBOK® Guide; focuses on ensuring that project information is generated, collected, disseminated, stored, and disposed of in an appropriate and timely manner.

Communications planning: the process of determining what information will flow into and out of the project and who wants or needs that information.

Constraints: any limitations imposed on the project or solution; typically falls into the categories of time, cost and resources, scope, and quality.

Contingency plan: response plan formulated for identified risks if/when a risk is realized.

Cost/benefit analysis: technique focused on the identification of the associated costs and the related benefits.

Cost Management: one of nine Knowledge Areas identified in the PMBOK®Guide; focuses on planning, estimating, budgeting, and controlling costs so that the project is successful.

Crashing: identifying schedule compression alternatives along the critical path and taking action to decrease the total project duration; typically accomplished by adding resources to the critical path tasks.

Critical path: the longest path through the project network; the sequence of activities that defines the minimum time required to complete the project.

CRUD matrix: static modeling technique that looks at how each data element is created, read, used, and deleted.

Customer: person or organization that will use the project’s product, service, or result.


Database Analyst: a person who reviews requirements for feasibility and completeness, and uses them as a guide in developing the system’s database.

Data dictionary: static modeling technique that provides a detailed description of each data element, including its source (for primary elements) or how it is derived or computed (for composite elements).

Data-flow diagram: dynamic modeling technique that shows how data is shared among the various activities and entities in a system.

Data transformation/mapping: static modeling technique that shows the changes data elements go through.

Decision package: provides information that the decision makers need to make a decision about the proposed project; almost always includes both a document and a presentation.

Decision tree technique: provides a structure within which you can identify options and investigate the potential outcome of following these various options.

Decision tree: decision support tool that uses a graph or model of decisions and their possible consequences, including chance event outcomes, resource costs, and utility.

Decomposition: process of breaking something down into smaller constituent pieces; most effectively accomplished through the use of a work breakdown structure (WBS).

Deliverable: any unique and verifiable product, result, or capability to perform a service that must be produced to complete a process, phase, or project; the solution due to the customer at the end of a project.

Delphi: consensus-based estimating technique using anonymous inputs from the team working on the project.

Dependency: logical relationship between two schedule activities.

Developer: a person who reviews requirements for feasibility and ensures understanding; responsible for creating a product that satisfies the requirements.

Document analysis: requirement elicitation method that studies available documentation to leverage existing material; can be time-consuming and often information may be out of date.

Duration: actual amount of time to complete the activity or the actual time on task; measured as elapsed work time, includes resources


Earliest completion date: first date the project can be finished by; determined by adding the time to complete all of the activities on the critical path.

Effort: amount of actual work in an activity; measured in hours or staff days.

EFT: Early Finish Time; earliest point in time in a project network an activity can finish.

Eight-Stage model: leadership-based model of change including: Urgency; Guiding Coalition; Vision and Strategy; Communication; Empowerment; Short-Term Wins; Consolidation and Production; and Anchor New Approaches.

Elicitation: techniques used to extract requirements information from people, as well as from other sources.

Enterprise Analysis: one of six knowledge areas identified by the BABOK; analyzing needs and opportunities from the overall organizational perspective and recommending projects to improve specific business processes and systems.

ERD: Entity Relationship Diagram; static modeling technique that looks at the data entities in a system and how they relate to each other.

EST: Early Start Time; earliest point in time in a project network an activity can begin

Event identification: dynamic modeling technique that shows the events the system must respond to, and what its response should be to each.

Evolutionary prototype: used with an incremental development life cycle to discover precisely what should be built, rather than trying to specify it in full detail before development begins.

Executive sponsor: ultimate authority on the project.

Expectation gap: results from clients, sponsors, and the team, each holding different views of the project.

External dependencies: dependencies that exist between schedule activities and factors outside of the project, like the output from another project or goods and services provided by vendors.


Fast tracking: attempts to reduce the overall project schedule by overlapping activities that would normally be done in sequence; requires an increase in planning and coordination between the overlapped tasks.

Feature: service the system/solution provides to fulfill one or more stakeholder needs; typically high-level abstractions of a solution that turn into functional or non-functional requirements; allow for early priority and scope management and for getting a high-level sense of the stakeholders view of the solution.

Financial risk: unexpected project costs; costs of implementing or operating the proposed process.

Finish-to-finish precedence relationship: similar to start-to-start relationships, except that the point of relationship is at the end of the activity; predecessor activity must be completed in order for the successor activity to be completed.

Finish-to-start precedence relationship: most common; the predecessor must be 100-percent completed before the successor can begin.

Float: amount of time an activity can be delayed without affecting the project end date.

Focus group: requirement elicitation method that involves an interactive session with a carefully selected group of people; can be an effective way to capitalize on the synergy of a group if all participants feel free to interact.

Forced-field analysis: relatively simple but powerful means of comparing the forces that favor and oppose a given decision; provides a basis for weighing the importance of the forces affecting the decision; provides a range of options for carrying out decisions.

Forward pass: in a network diagram, allows you to calculate the EST and EFT for each activity.

Free float: the amount of time an activity can be delayed without affecting successor activities.

Functional design: observable behaviors of the solution; as opposed to technical design.

Functional requirements: define what the system must be able to do; describe both the systems behavior in detail and the information the system will manage.


Horizontal prototype: mockup of a broad area of a system that has little or no actual capability to do work; often used to review user interfaces or work flows.

Human Resource Management: one of nine Knowledge Areas identified by the PMBOK® Guide; focuses on organizing and managing the project team members.


IIBA: International Institute of Business Analysts; professional association for business analysts.

Implementation requirements: special set of conditions or capabilities that are needed only during system rollout or implementation.

Information Architect: a person who reviews requirements for feasibility and completeness and then uses them to derive the system’s information needs.

Information architecture: part of the enterprise architecture that shows how data flows within the organization.

Infrastructure Analyst: a person who reviews the requirements for feasibility and uses them as a guide in establishing the operational infrastructure that is necessary to support the solution.

Integration Management: one of nine Knowledge Areas identified by the PMBOK® Guide; focuses on the processes that integrate the various elements of project management that are identified, defined, combined, unified, and coordinated in the project management process groups.

Interview: requirement elicitation method that offers the opportunity for rich communication by meeting with either an individual or group of people.


Lags: waiting time inserted between the activities in a relationship (i.e., downtime).

Leads: partial overlapping of activities; essentially a head start for one activity, relative to the other in the relationship.

Lessons learned: identified at the end of each stage of the project and collected for cumulative analysis; gathers and documents what went right and wrong, what should be done differently, and what would you recommend to others.

LST: Late Start Time; the latest time an activity can begin without jeopardizing the project end date.


Mandatory dependencies: also referred to as hard dependencies or hard logic; characterized by a required order in the relationship between the activities.

Milestone: significant point or event in the project; point in time of significant accomplishment in the project.

Mitigation: one of four possible strategies for response planning with regard to an identified risk; indicates that the risk cannot be tolerated at its identified impact level, but cost acceptable steps can be taken to reduce the risk impact down to a tolerable level; always results in residual risk.

Modeling: representations of a business or solution that often include a graphic component along with supporting text and relationships to other components.

Murphy’s Law: adage in Western culture that broadly states “things will go wrong in any given situation, if you give them a chance”; or shorter “anything that can go wrong, will”.


Needs: type of high-level requirement that is a statement of a business objective, or an impact the solution should have on its environment.

Non-functional requirements: required system capabilities that do not describe functionality; examples include the number of end users, response times, fail-over requirements, usability, and performance; also known as supplementary requirements.


Object-oriented modeling: approach to software engineering where software is comprised of components that are encapsulated groups of data and functions which can inherit behavior and attributes from other components; and whose components communicate via messages with one another.

Observation: requirement elicitation method that involves watching people as they go about their jobs; can be an effective way to gain an understanding of how work is done in the production environment; can be time consuming and may disrupt work.

Open-ended surveys: allow the respondent to write out answers in their own words; are more difficult to analyze quantitatively than closed-ended surveys.

Operational management: focused on the development and execution of programs that sustain the organization and move it forward.

Optional dependencies: relationships in which the project manager has some influence over the sequence of the relationship; often referred to as soft logic dependencies or discretionary dependencies.


Paired-comparison analysis: technique for calculating the importance of a number of options relative to one another; especially useful when you do not have objective data to base the decision on.

Pareto principle: also called the 80/20 rule; based on Pareto’s study of the concentration of wealth in Italy that found 80 percent of the wealth was held by 20 percent of the people.

Pareto analysis: used for finding the changes that will yield the greatest benefits; particularly useful in situations with many competing alternatives.

Parkinson’s Law: concept that states “work will always expand to fill available time”; padding or expanding estimates simply encourages procrastination.

Passive/invisible observation: observing in a way that does not disturb the workers being observed.

PDM: Precedence Diagramming Method; places activities in boxes and shows the precedence relationship with arrows; also known as AoN (Activity on Node) or EoN (Event on Node).

PERT: Program Evaluation Review Technique; uses multiple points of estimate for the same activity to derive a weighted average estimate for the activity.

Phase: a collection of logically related project activities, usually culminating in the completion of a major deliverable.

PMBOK® Guide: Abbreviation for PMI’s Guide to the Project Management Body of Knowledge.

PMI: Project Management Institute, Inc.; professional association for project managers.

PMP®: Project Management Professional; certification offered by PMI.

Process: set of interrelated actions and activities performed to achieve a specified set of products, results, or services.

Product: solution, or component of a solution, that is the result of a project.

Product metrics: based on the product scope and requirements; give insight into whether the product being built will achieve its goals.

Project: (for project managers) unique, non-routine endeavor requiring an investment decision that has defined and agreed upon objectives and a start and end date; (for business analysts) specific, detailed, and coordinated steps through which programs accomplish the changes defined to enact the strategic plans.

Project charter: document issued by the project initiator or sponsor that formally authorizes the existence of a project, and provides the project manager with the authority to apply organizational resources to project activities.

Project Manager (PM): person ultimately responsible for the project, including ensuring that the final product satisfies the requirements.

Project metrics: based on the project’s goals and give insight into whether the project is likely to achieve those goals.

Project objectives: definition of what the project will accomplish.

Project risk: things that may impact the project’s ability to meet stakeholder expectations; uncertainty (both positive and negative) that matters to the project.

Prototyping: usage modeling techniques that mocks up a user interface, or the flow of screens or forms in a user interface, for review.


QA Analyst: a person who reviews the requirements to ensure that they are testable and that they meet quality standards and policies; responsible for testing the product after it is developed to see if the requirements were indeed satisfied.

Quality of Service (QoS) requirements: explain the way in which the system must provide the functional requirements (i.e. response times, security, usability, and maintainability); often called nonfunctional requirements.

Quality assurance: planned and systematic quality activities to ensure requirements are met.

Quality control: monitoring specific results for compliance with relevant quality standards.

Quality Management: one of nine Knowledge Areas identified by the PMBOK® Guide; focuses on ensuring that the project will satisfy the needs for which it was undertaken.

Quality planning: phase of identifying relevant quality standards and how to satisfy them.


RAM: Responsibility Assignment Matrix; structure that relates the project organizational breakdown structure to the WBS to ensure that each element of the scope of work is assigned.

Resource: includes skilled human resources (specific disciplines, either individually or in teams), equipment, services, supplies, commodities, materials, budgets, or funds.

Resource leveling: technique used to address resource overloads and ensure that resources are expected to perform realistically.

Resource load: total amount of assigned work within a timeframe.

Requirement: condition or capability needed by a stakeholder to solve a problem or achieve an objective.

Requirements Analysis and Documentation: one of six knowledge areas identified in the BABOK; making sense of the information that is elicited, organizing it, and documenting it in appropriate forms (that is, words, tables, models, and prototypes); describes how business, functional, and nonfunctional requirements can be assessed, documented, and presented.

Requirements analysis: defines the methods, tools, and techniques used to structure the raw data collected during requirements elicitation; identifies gaps in the information and defines the capabilities of the solution.

Requirements attribute: characteristic of a requirement that captures additional information, such as priority or level of risk.

Requirements Communication: one of six knowledge areas identified in the BABOK; involves providing requirements information to those who need it, when they need it, in the form that they need.

Requirements communication plan: defines the communication activities during a project used to ensure that requirements information is available to all project members when it is needed, and in a usable form.

Requirements discovery session: a forum (like a JAD) where stakeholders and SMEs get together to provide information about the target system.

Requirements document: captures and communicates gathered requirements.

Requirements Elicitation: one of six knowledge areas identified by the BABOK; the collection of activities and approaches for capturing the requirements of a target system from requirements information from various sources and stakeholders.

Requirements package: all the items that comprise the requirements for a project; defined based on the stakeholders for whom they are built and their needs and preferences.

Requirements planning and management: one of six knowledge areas identified by the BABOK; includes producing a plan for determining requirements activities on a project, and keeping those activities on track; includes managing changes to individual requirements and project scope

Reverse engineering: analyzing an existing system to understand what it does and why.

Reverse engineering requirements: method of identifying requirements by interviewing developers, reading code, and testing applications.

RFP: Request For Proposal.

RFQ: Request For Quote.

Risk mitigation: risk response strategy that takes action to reduce the probability and/or impact of a risk.

ROI: Return On Investment.


Satir change model: system view of change including seven stages: Old Status Quo; Foreign Element (change); Chaos; Transforming Idea; Integration; Practice; New Status Quo.

Scope: sum of the products, services, and results to be provided as a project.

Scope creep: changes that occur during a project that are neither recognized, evaluated, nor approved.

Scope exclusions: specifically indicate what work falls outside of the project boundaries.

Scope inclusions: indicate what the project is about and what it will do.

Scope Management: one of nine Knowledge Areas identified by the PMBOK® Guide; focuses on ensuring that the project includes all the work required, and only the work required, to successfully complete the project.

SDLC: Software Development Life Cycle.

Security architecture: part of the enterprise architecture that shows the security needs and practices within the organization.

Sequence diagram: dynamic modeling technique that shows the exact steps for a specific scenario; shows objects participating in interactions and the messages exchanged.

Sign off: formal, written approval gained throughout the project management processes at the end of a phase.

Solution Assessment and Validation: one of six knowledge areas identified by the BABOK; focuses on collaborating with the technical and quality assurance teams to ensure that the solution built satisfies the requirements and collaborating with business users to plan acceptance and rollout of the solution.

Solution owner: major supplier of requirements information, and is often an approver of the requirements; also referred to as the customer.

Sponsor: person or group that provides the financial resources for the project.

Stakeholder: persons or organizations that are actively involved in the project, or whose interests may be positively or negatively affected by execution or completion of the project, or who can exert influence in project decisions.

Start-to-finish precedence relationship: the predecessor activity that must begin in order for the successor to be completed; relatively rare.

Start-to-start precedence relationship: predecessor task that must be started before the successor task may be started.

State Machine Diagram: dynamic modeling technique that shows all the states the system can be in, and the possible transitions among those states.

States: exist in a system if the same input generates different responses in different situations; for example, a hotel has two states: “vacancy” and “no vacancy”, and a request for a room generates different results in those two states.

Storyboard/screen flows: usage modeling technique used to mock up a user interface, or the flow of screens or forms in a user interface; differs from a prototype in that these are not functional systems, rather they are often drawings.

Strategic planning: systematic and formalized effort to establish organizational purposes, objectives, and policies, and to develop plans to implement them.

Structured interview: has a detailed agenda and formal set of questions.

Subject Matter Expert (SME): a person who provides many important requirements, and in certain situations, may need to approve requirements.

Survey: requirement elicitation method that allows you to collect information from many people in a relatively short period of time.

SWOT (Strengths, Weaknesses, Opportunities. and Threats) Analysis: method of identifying project benefits.


Task: component of work performed during the course of a project, also called activity.

Technical constraints: limitations imposed on the solution related to business activities (i.e. architecture decisions that are made).

Technical risk: technological changes that could impact the project or technologies that may not work as expected.

Technical requirements: state requirements in terms that the implementation team needs (i.e. system or software requirements).

Technology architecture: part of the enterprise architecture that shows how different technologies support the business.

Throw-away prototype: prototype used to answer specific questions as a basis for development but is not meant to be used in the final system.

Time Management: one of nine Knowledge Areas identified by the PMBOK® Guide; focuses on ensuring that the project is completed in a timely manner.

Traceability: information that shows stakeholders the relationships between individual requirements and their sources; allows a BA to manage scope creep and ensure all requirements have been met.

Traceability association: exist between requirements when more detailed requirements are associated with the higher level requirements (i.e. needs and features); can also exist between detailed requirements and design models/test cases.

Transference: one of four possible strategies for response planning with regard to an identified risk; indicates that the risk cannot be tolerated but the cost of elimination is too great, so ownership of risk response and impact are shifted to a third party.

Triple-constraints model: notes the relevant constraints of time, scope, and cost/resources that are shared by all projects; provides a basis for planning project controls.


Unstructured interview: has only a loose agenda, depending more on ad hoc interaction.

Use-case descriptions: usage modeling technique that identifies the specific steps that will happen in a particular transaction (or use case) along with entry and exit conditions and other relevant information; usually necessary to describe the use cases depicted in a use case diagram.

Use-case diagrams: usage modeling technique that captures all actors and use cases involved with a system or product.

User interface designs: usage-modeling technique that is similar to storyboards and screen flows, but used much earlier in the analysis process.

User profile: usage-modeling technique that lists the end users of a system, including relevant attributes of each.

User requirements: subset of business requirements that address the needs of specific users to do their jobs.

User story: usage-modeling technique that is similar to use case descriptions, but with much less detail.


Validation: checking requirements to be sure that they are correct, complete, and feasible.

Verification: checking requirements to ensure that they have been written and specified well; should be done before validation.

Vertical prototype: detailed view or functional model of a narrow area of a system; often used to test the feasibility.


WBS: Work Breakdown Schedule; deliverable-oriented, hierarchical decomposition of project elements that defines the total work scope of the project.

Wide-band Delphi: works just like normal Delphi, except that the successive estimating rounds focus on the inputs that PERT requires.

White box reverse engineering: examines the program code and other technical details to determine not just what it does, but why and how it does those things.

Work package: deliverable or project work component at the lowest level of each branch of the WBS.

Workflow models: dynamic modeling technique that diagrams the flow of activities among responsible parties.

Workshop: requirement elicitation method that involves a structured meeting with a group of people to generate many ideas in a short period.


Aftermath of Hurricane Ike

Filed under: Hurricane — by Donna Ritter @ 6:18 pm

Well, Hurricane Ike was a bit more destructive than we thought. We lost power for almost 5 days, there was no gas or food to be had and we lost most of our fence including a tree that fell across our fence onto a neighbor’s garage.

We did have fun playing board games and cards by candlelight, but that gets very old after 2 days. Luckily the weather had cooled off somewhat, so we could sleep without air conditioner. It is amazing what creature comforts we take for granted!

When we said grace every night, we thanked God that we were so lucky. Some of the areas around here are very flooded. They won’t let residents back on to Galveston Island yet – they can go visit to see the damage, but have to be off by 6:00.

Maybe next time we should consider evacuating J.

Next Page »

Create a free website or blog at