rpCamera's timing and related rules for creating QR Snapshots
V 2.2 -3/26/11 DMa Explaining when and how rpCamera™ takes place ... and how its rules compensate for various user needs and behaviors.
To keep work quality information up-to-date, rpCamera is made available at the first of each month in the rpDashboard™.
rpCamera™ is designed to be used by each party within a work relationship once per calendar month.
rpCamera is normally made available to both parties on the first day of each month. rpCamera will remain available for the entire calendar month until each party completes their portion of the input (aka: Snapshot). After both parties have completed rpCamera, each are presented a completed QR Snapshot™ in their rpDashboard™. This shared information assures that both parties have a better understanding of the quality of their work relationship for the past month. Both parties are encouraged to complete their rpCamera Snapshots as soon as possible each month to gain maximum benefit including QR quality validation and having the greatest window of time for responses (such as dialogs of QR concerns and the pursuit of QR improvements).
More about rpCamera:
- In the typical monthly usage that follows, each party will again be offered a new rpCamera on the first day of each following calendar month so both can once again create an up-to-date QR Snapshot for their relationship over the last month's interval.
- Once an rpCamera is used for a relationship within a calendar month it no longer will appear in the rpDashboard for the balance of that month.
- The word "month," whenever used or applied in rpCamera's rules, always implies a calendar-based month.
- A QR Snapshot is complete (or "consummated") at the point the last of the two parties submit their respective quality ratings. When this occurs the QR Snapshot's date is established and it immediately appears in the rpDashboards of each party.
- In normal usage, and in all of the below scenarios, weekly alert/reminder e-mails will be sent to either user, as applicable, notifying the user that "action is required" in their rpDashboard.
- A QR Snapshot is considered to be out-of-date when it is older than the current month. At the end of each month, any existing QR Snapshot icon on the rpDashboard will turn to a brown color, as will its related rpMat. A QR icon will remain brown until an up-to-date QR is created (by both parties providing their respective Snapshots in the new and current month).
However, there are exceptions ...
1) Since each of the two parties act separately as rpPaq users to create (or consummate) a single completed QR Snapshot, and ...
2) Since at times one or both of the two parties may be otherwise absent, passive, distracted or unresponsive for an extended period of time,
... rpCamera accommodates certain related situations by applying certain rules based upon the two parties' (or users') respective behaviors or circumstances. Each of these different situations are known as "scenarios." Each of these scenarios are defined and explained in greater depth below (scroll down to view).
In sum, each party is offered a "two calendar month window" to respond to the other party's use of the rpCamera, ... although this is less than ideal and is not advised, unless there are extenuating circumstances or reasons for such delays.
For an overall logic summary of the rpCamera behaviors, scroll to bottom section of this lesson.
Scenario A: Initial rpCamera set-up that establishes the relationship and creates the first QR Snapshot.
User #1 creates a new work relationship in their rpDashboard (either "to which I report" or "my direct reports"). As they do this, they create and share their first monthly work quality perspective.
When they complete their input, an invitation is sent to User #2 by an e-mail inviting them to go to rpCamera and insert their perspectives.
Once both parties have entered their respective perspectives of work quality for the beginning or first month, a QR Snapshot becomes available to each of them within their rpDashboards.
At the beginning of the following month, and all subsequent months, each party's new rpCamera is made available to them to capture and present their work quality perspectives.
Both parties are also automatically notified via email that rpCamera is ready for their usage at the beginning of each month.
Scenario B: One party initiates rpCamera in a given calendar month, but the other party does not respond until the following calendar month.
When the recipient party #2, of a new relationship, fails to respond during the same month in which they received the e-mail invitation, they still can do so during the second month.
Note that in this scenario, User #1 will not have a new rpCamera for that relationship within their rpDashboard during the 2nd month.
Yes, this means that User #1's input may not be as "up-to-date" as User #2's;
thus timely response within a calendar month benefits both parties.
Tip: In many cases it may be best not to initiate a new relationship at the end of a calendar month, since the other party may not have time to reasonably respond during that month.
Scenario C: One party initiates rpCamera in a given calendar month, but the other party does not respond in that month, nor do they respond within the second calendar month.
When the recipient party #2, of a new relationship, fails to respond during the same month they received the e-mail invitation, and again fails to do so in the following 2nd calendar month, the relationship is considered void.
Note 1: In such cases, this relationship must then be reinitiated or reestablished in the same manner as any other new relationship.
Note 2 : Once more in this scenario, User #1 would not have an rpCamera in the 2nd month (per Scenario B).
Scenario D: During on-going activities, if either party fails to respond to the other party's input within any given calendar month, they can do so within the next calendar month.
When the recipient party #2, in an on-going relationship, fails to use rpCamera during any given calendar month, they still can do so during the following second calendar month.
Note 1: In this scenario, User #1 will NOT have a new rpCamera within their rpDashboard for their current expression during the 2nd month.
Note 2: Yes, this means that User #1's input may not be as "up-to-date" as User #2's; thus, timely response within a calendar month benefits both parties.
Note 3: Once more in this scenario, User #1 would not have an rpCamera in the 2nd month (per Scenario B).
Scenario E: In an established relationship, if one party fails to respond to the other within the present and 2nd calendar month, they must begin anew with "fresh" rpCameras.
When the recipient party #2, in an on-going relationship, fails to respond during the same month they received the e-mail invitation, and again fails to do so in the following 2nd calendar month, at the beginning of the third or later months, each will be provided with new rpCameras.
Note 1: User #1's prior camera to which there was no response by User #2 for two months will be void, since it is no longer current.
Note 2: Once more in this scenario, User #1 would not have an rpCamera in the 2nd month (per Scenario B).
Overall rpCamera Timing Logic : Here's an alternative view of the "if > then" logic of the all of the above scenarios...
If you are still confused by the above scenarios, here's the logic of the rpCamera's availability "in a nutshell." You will note that for every scenario, there are just three conditions of "if > then" logic. Note: a "consummated" QR is when both party's respective QR Snapshots are combined to create the QR Snapshot for a given month (which occurs when the last party completes their input within an applicable time period).
G E N E R A L T A L E N T LLC All rights reserved 2011 Patents & patents pending. License required for any usage or applications.