We can’t speak for certain Gingerbread Land expats, but for all Gingerbread-folk who still live in their homeland and for most of the ones who live abroad, the cadence of Gingerbread life is marked by the steady beat of projects. A typical Gingerbread person measures their existence by the quality and quantity of projects they’ve participated in and/or completed, and if you ask a Gingerbread person, “How are you?” they’ll instinctively update you on the status of their current project. Gingerbread people need no food, drink, or rest. Their entire lives revolve around projects and the social interactions necessary in the initiation and execution and completion of those projects.
As your corps of Gingerbread folk prepare for their adventure, they’ll quite naturally approach the journey as a series of projects. So, time will have to be taken to do some project management.
There are three steps involved in Project Management: Assessment, Design, and Implementation.
Assessment
Once it becomes clear that a particular situation will require a project in order to be properly dealt with, the group must assess the situation further to determine the relevant facts and define the specific Challenge at hand. The Assessment phase is completed when the group finalizes a Project Objective.
The process of assessment unfolds as follows:
Step 1: Project called for…
A project may be called for when the following criteria are met:
A) A situation has arisen that leads the players to suggest the building of a complex object and/or the forming of a complex plan in order to cope with the situation. One or two players overcoming obstacles, creating advantages, initiating conflict, or digging in for defense isn’t going to properly deal with what’s going on. Something more coordinated and thought-out is required.
B) The object/plan sounds like it’ll be something that involves a coordination of skills from all of the PCs.
The GM can certainly point out when a moment like this has arrived, but, hopefully, the players will spot the opportunity themselves.
After the group asserts that a project is necessary, they begin a process whereby three observations about the situation are determined.
Step 2: Determining Observation 1
All players roll simultaneously, each attempting to create an advantage using a relevant skill against a difficulty of Good (+3). The players may utilize whatever skills they like, but they should be encouraged to each use a different skill.
That said, the most important things to consider in choosing which skill to use include relevance to the situation at hand – the skill should be as relevant as possible – and relevance to the contribution the player would like to make to the project. For example, if the situation seems to call for an armored vehicle and the player would like to move the assessment towards that project objective so that the PC may contribute to building the armor, the player will utilize the M-S skill.
Also important: Whatever skills a player chooses for this phase will be the skills available to them in the Design and Implementation phases.
Everyone will note their final roll result. Presuming more than one person succeeds, the person with the best success is the first observer. Players who tie for the best success will re-roll until a clear “winner” is determined, but the first roll is the one that will be used for the rest of this step so, again, be sure that it’s noted.
Next, the first observer must measure the strength of their observation – based upon margin of success on their first roll – using the following table:
Margin Result Strength
None Fail 0
0 Tie 1, at a cost
1-2 Success 1
3+ Success with Style 2
The GM determines a minor cost in the case of a tie.
At this point, the first observer presents a situational observation that will become a situation aspect. The observation can be anything, so long as it fits the skill the observer rolled against, is relevant to the situation, and, by other entities in the game world, would be readily and objectively observable. It’s very important that the observation is not an opinion or a guess about what’s so. It must be, to all in-world entities, an immutable, verifiable fact.
Up to now, we’ve presumed that players succeeded in their initial rolls. What if nobody succeeds in the first roll? In that case, the first observation of the Assessment will be left blank, impacting the strength of the final Assessment.
Step 3: Determining Observation 2
Begin this step just like the last to determine the second observer. Players can pick a different skill if they like or use the same one. The skill just needs to be relevant to the present scenario.
Remember that whatever skills you utilize in the Assessment phase will be available to you in the Design and Implementation phases, but only those skills will be available to you. So, if you use the same skill for each observation, only that skill will be available to you later. Obviously, three skills is the highest number you can have available in the Design and Implementation phases.
The roll in this step is a little different than in the previous step, in that the roll to beat is the winning roll of the previous step. So, if the winning roll in Step 2 was +4, the roll to beat in Step 3 is +4.
Remember to have the second observer note the strength of their observation, as determined by the table above.
If there was no winner in Step 2, then in Step 3 everyone will roll against +3.
If a situation aspect was successfully created in Step 2, it can be invoked in Step 3. Whoever created the aspect gets the first crack at it, and they may either invoke, not invoke, or claim the invoke to pass to some other specific player (the player who the invoke is passed to is then considered “the invoker”).
If the invoke results in the invoker winning the roll, the new situation aspect they’re now privileged to create must take the invoked aspect into account. It must not neutralize or even significantly deviate from what the observation in the aspect has already determined as truth.
If nobody wins the roll, the second observation in the Assessment is left blank.
Step 4: Determining Observation 3
Repeat Step 3 to determine the third observer, including making the roll to beat the winning roll of the previous step or +3 if there were no winning rolls in Step 3. Also, if there are no winning rolls in Step 4, then the third observation in the Assessment is blank.
Remember to have the third observer (if there is one) note the strength of their observation, as determined by the table above.
Step 5: Define the Challenge
Here’s where the strength points come in.
Add up the strength points accrued (if there are any) by all the observers (if there were any).
If the total number of strength points is two or less, then the Assessment fails as a whole as your group was unable to acquire an adequate grasp upon the situation.
This doesn’t mean the project cannot go forward. The group can decide to abandon the project, certainly, but they may also push ahead with a poor Assessment. If they choose to push ahead, the poor Assessment will become a situational aspect that the GM can use to create complications for the group. Also, any situational aspects that were created during the Assessment process will stay active until they’re no longer relevant, and the GM is allowed to invoke them at will.
If the total strength points equal three or more, then the Assessment is a success. Have all players roll to see who can get the highest total. Let each player who contributed an observation to the Assessment take a +2 bonus for each observation they contributed.
Whoever wins this role will define the Challenge based upon all of the available observations. The Challenge must take all of the observations into account. The Challenge becomes an aspect while all of the observation aspects go away.
The number of free invocations on the Challenge aspect depends upon how many strength points were accrued by the observers:
Strength Result
0-2 Failure—we don’t have an adequate grasp of the challenge
3 Tie—challenge aspect
4-5 Success—challenge aspect with one free invocation
6 Success with Style—as Success, but two free invocations
With the Challenge established, the players simply negotiate to decide upon a Project Objective. If the Challenge is weakly understood or bafflingly vague due to few or no observations, it makes no difference – the Challenge remains the foundation of the Project Objective negotiations.
A good Project Objective starts with a clear, concise, positive statement of what will be done (“Steal the plans…”, “Build a ship…”, “Frame the mayor…”) followed, if needed, by a clarifying clause (“… from the monkeys…”, “… out of coconut husks…”, “… for stealing the missing tin…”) followed, only if absolutely needed, but a third and final clause (“… while keeping our presence a secret”, “… and palm fronds”, “… while we make off with the tin ourselves”).
The Project Objective will be a function aspect of the product or plan you create in the Design phase of Project Management.
Example of three Observations, the resulting Challenge, and the final Project Objective:
Observation 1 – Blackstrap’s armored forces are a day away at their present rate of travel.
Observation 2 – Materials for armor and munitions are on hand.
Observation 3 – No one in the party has M-S, M-F, E&M, or Fabrication as their main skill!
Challenge – Less than a day to create armor/weapons with no top experts on hand!
Objective – Build fully armed tank with the help of locals through the use of “soft skills”
Design
Projects result in the creation of products or plans. A product is a material thing and its design is the process whereby the component elements are determined, the raw materials are identified and gathered, the component elements are constructed, and the finished elements are assembled into the final product, which we may call “The Build”. A plan is, obviously, not a material thing and its design involves a strategy to coordinate player skills to achieve the Project Objective. Specifically, the plan determines player roles, identifies necessary tools, equips players with said tools, and solidifies the narrative of the plan, which we may call “The Job”.
A Build is a comparatively straightforward affair – find materials, craft components, assemble the product. Major vehicles, weapons, bombs, traps, etc. might all be made by such a process, as is probably self-evident at this point. A Job, however, may not seem quite so straightforward, so it merits a bit more attention here.
Strategic plans can find their ways into any game, but especially those where the players have selected few or no Occupation skills, opting for Profession skills instead. Innovative stunt-creation aside, it isn’t obvious how Subterfuge will help one formulate fuel. Or how Trickster will hammer ore into armor plating. Your Gingerbread corps rushes out to face a dire threat! How can they successfully do so with only so-called “soft skills” at their disposal?
War is an interesting thing, when you really think about it. A dreadful thing, of course, but intriguing nonetheless. That’s the exact proper word, too… intriguing. Because not all battles are fought with weapons and explosions. Not all traps maim or kill. Sometimes what is actually needed is a touch of vandalism. A pinch of theft. A smidge of espionage.
Or, if hardware is absolutely essential, the proper motivation applied to certain locals – by the use of an impactful propaganda campaign, a substantial bribe, or a devastating bit of blackmail – can recruit an entire village-worth of people to bring your war machine to fruition.
So, it is of utmost importance that specific skills are not underestimated. A game where the entire corps of Gingerbread folk constitute a popular theater troupe has the potential to be every bit as interesting and exciting as a game were every player has a different very practical Occupation that, when all are taken together, make the group exceptionally gifted in blowing things up.
To begin the Design phase of Project Management, the Project Objective requires more fleshing out.
Step 1: Establish product/plan capabilities
Whether a Build or a Job, there are things it’s meant to do. Build capabilities might include “fire 50mm rounds” or “deflect 50mm rounds” while Job capabilities might include “inspire highest quality work” or “negotiate lowest cost for assistance”. These will be noted as stunt benefits for the Build or Job. For example: Takes a punch – Armor=3; Bigshot – one shot per turn, but +3 to Combat; We still have our FREEDOM! – +2 to Smooth when relying on non-Gingerbread folk for M-S, M-F, E&M, or Fabrication; Shoe-string budget – +2 to Smooth when relying on non-Gingerbread folk for Prospecting.
There are three restrictions in this step.
First, when creating capability stunts, they must address the Project Objective in some reasonable way.
Second, there can be only as many capabilities as there are players participating in the project. So, if there are four players and all of them are in on the project, there can be four and only four distinct capabilities.
Third, each capability must relate to a skill the player called upon in the Assessment phase. If a player called upon two or three skills in the Assessment phase, they may utilize any one of those two or three skills, but only one skill per capability. So, if the four players offer Trickster, Smooth, B&E, and Smooth to the project, then one capability must be related to Trickster, two must be related to Smooth, and one must be related to B&E.
Step 2: Determine product/plan parts
This step amounts to deciding what parts – as in, components – a Build will have or what parts – as in, roles – individuals will play in the implementation of a Job. Presuming four players, four parts of a Build might be “tank armor”, “tank gun”, “tank drive system”, “tank targeting system”. Four parts of a Job might be “palm greaser”, “materials smuggler”, “distraction”, and “intimidator”. Once again, the parts determined will be derived from the skills used by each player during the Assessment phase. The players determine the parts in open discussion.
Step 3: Build the Build/Equip the Team
If the project is a Build, then each player will roll against +3 for their contribution to the build. Once this is done, the product is considered assembled and whole, but the quality of each piece of the whole may vary as informed by the following table:
Roll Result
0-2 Component will work, but there will be a major consequence
3 Component will work, but there will be a minor consequence
4-5 Component will work
6 Component will work and create an advantage
The consequences/advantages impact everyone who participated in the project. The GM will hold consequences/advantages in reserve to determine what they are during the Implementation phase.
So, if there are four players working on the project to, say, build a tank and all rolls fail, the tank will be constructed and operational, but four major consequences will befall the entire group. If all rolls are +6, then four advantages will be created along with the fully operational tank. These are the worst- and best-case scenarios for this example.
If the project is a Job, then each player will roll against +3 for one piece of equipment that they may use to assist them with their part of the plan. The piece of equipment may be specified by the player so long as it fits the story and is within reason. The player will always get the equipment and the equipment will always do what it’s supposed to do, but the quality of the equipment will be informed by the following table:
Roll Result
0-2 Equipment will work, but there will be a major consequence
3 Equipment will work, but there will be a minor consequence
4-5 Equipment will work
6 Equipment will work and create an advantage
The consequence/advantage impacts only the person who’s using the equipment. The GM will hold consequences/advantages in reserve to determine what they are during the Implementation phase.
So, if a player needs, say, a lockpick to do a Job and the roll fails, the lockpick will do what it’s supposed to do, but a major consequence will be experienced by the lockpicker. If someone else needs to use a forged document to do a Job and they roll a +6, then not only will the document work as intended, but the player will receive an advantage later. These are the worst- and best-case scenarios for this example.
Step 4: Assign risk
In this step, players create aspects for their Build/Job and for their situation.
The Build/Job aspects point out a flaw in the Build/Job. For example, if the Build is a tank, a valid Build aspect may be “Extremely heavy”. Or, if the Job is an espionage plan, a valid Job aspect could be “One person short”. These must be real, unsolvable problems with the Build/Job based upon the nature of the thing, not, say, random glitches.
The situation aspects point out a thing or things that the players risked in undertaking the project, risks against which they could not mitigate. Examples might include “Lost the element of surprise” or “Allowed the enemy to get a day closer” or the like.
Only one flaw is required per Build/Job, but more can be added if the players think more might make things more interesting. A player who successfully suggest extra flaws and gets the rest of the team to agree to them receives a Fate point.
For every stunt benefit the Build/Job has, make one situation aspect that represents an unmitigable risk. The GM may allow Fate points to be used to mitigate these risks anyway if the player can come up with a compelling/fun narrative justification.
Implementation
Time to put the Build/Job into action!
While Step 3 above already tells us that our Build/Job will function and whether or not it will bring a consequence or advantage, we still don’t know how well it will perform its stunts and if it will be successful in whatever it was designed to do. The consequences/advantages float out there, waiting for the GM to decide what they are at the opportune time. Whether or not the Build/Job ultimately achieves its Project Objective is really a separate issue entirely.
In the Implementation phase of a Build, one player – preferably the one with the highest skill most relevant to the Project Objective, which is, recall, a functional aspect of the Build – will be selected to deliver the device, whatever that means, i.e.: operating the device, triggering the device, placing the device in a particular location, etc. This player will execute all rolls relevant to delivery of the Build using aspects/stunts of the Build and/or the player’s relevant skills. Other players can use Fate points, aspects, or skills to +1 the player delivering the device, but if a player uses a skill, it must be different from the skill the delivery-player is using.
In the Implementation phase of a Job, each player rolls as is appropriate for the role they’re playing in the execution of the Job, also utilizing stunts and/or Fate points as needs be.
The Project concludes when the Project Objective is achieved or failed.
We use cookies to analyze website traffic and optimize your website experience. By accepting our use of cookies, your data will be aggregated with all other user data.