Archiolabs, an innovative B2B SaaS company specializing in cloud-based planning tools, takes part in one of the industry's most important trade fairs every year. The trade fair appearance is a central project for Archiolabs, planned and executed from scratch every year. It’s the perfect chance to stay in touch with existing clients, generate new leads, and boost their brand in direct conversation with their target group – planning offices, architects, and project managers.
But preparing for the fair is complicated and time-consuming every single year. There are lots of steps to line up – from booking the booth to developing the booth concept all the way to planning how everyone gets there, booking hotels, transport, booth staffing, and post-event follow-up. Since the trade show only comes once a year, team members often forget exactly what needs to be done and how things work in detail. That ends up causing regular delays, extra work, and needless stress.
To tackle these challenges, Archiolabs decided to create a standardized project component for the trade fair appearance. This component is designed to:
Structure the whole process clearly and serve as a template.
Speed up and simplify yearly planning.
Document each step clearly so no one ever has to start from scratch.
Use the lessons learned from past years to keep improving the process.
In this workshop, we're going to work out the structure and content of this project component. Together, we'll define:
Which recurring sub-tasks are part of the trade fair preparation.
What dependencies and sequences exist between the tasks.
Which info, checklists, and data points are needed to control the project.
How to design the component so it can be used as a reliable tool for all future trade fair appearances.
At the end of the workshop, there should be a first draft of the project component that serves as a template for practical implementation in Archiolabs' planning system.
Ben Heinrich gathered the team in the meeting room. The team is sitting at the big conference table. Ben Heinrich is leading the discussion, Florian Bauer has Leadtime open on the screen, which is projected onto the big monitor. Coffee mugs are on the table, notebooks are ready.
Ben Heinrich (Managing Director): Workshop initiator, overview of the strategic importance of attending the trade fair.
Laura Keller (Sales Assistant): Responsible for coordinating and scheduling the meetings at the trade fair.
Lena Friedrich (Executive Assistant): Responsible for all organizational tasks – booking hotels, transport, stand space, and orders.
Katja Fischer (Project Manager): Responsible for booth design, print materials, flyers.
Johannes Klein (Support Specialist): Worked at the booth last year – knows how everything works on site.
Florian Bauer (Senior Project Manager): Lead time specialist, joins the workshop and handles the project component implementation at the same time.
Ben Heinrich: "Alright, let's get started. Our first goal is to define the big topic areas – the so-called Epics. These are the main building blocks of our trade show prep, and everything is based off of these. Each Epic stands for a clearly defined area that pulls through the whole project like a common thread."
Lena Friedrich: "So these are basically the super chapters, so we don't drown in a hundred little tasks again later, right?"
Ben: "Exactly. These Epics help us structure the project clearly. If we define them well today, we can avoid chaos a few months from now. Florian, you've got Leadtime open, right?"
Florian Bauer: "Yep, ready. I'll create the Epics right there live with you."
Ben: "Awesome. Let's start gathering the big topics – what are the monsters that eat up our time and nerves every year?"
Laura Keller: "The appointment planning. The customer meetings at the trade show and all the coordination before. That is always a huge task."
Ben: "Yep, that's definitely its own Epic. Florian, please create one as 'Trade Show Appointment Planning'."
(Florian types and adds “Trade Fair Scheduling” as an epic.)
Lena: “Bookings and orders – the whole logistics: booth space, hotel, rental car, catering, electricity, stand builder… that’s a huge deal.”
Ben: “For sure. I’d call this ‘Organization & Bookings.’ Florian?”
(Florian adds “Organization & Bookings” as an epic.)
Johannes Klein: “Stand duty. So, who’s at the booth when, who’s taking breaks. Last year we just did it spontaneously – never again.”
Ben: “Exactly, it’ll go better this time. ‘Booth Support & Duty Plan’?”
(Florian adds “Booth Support & Duty Plan” as an epic.)
Katja Fischer: “Design and setup. The booth, the furniture, the graphics – everything that’s there physically and visually. There’s a ton of work in that every year.”
Ben: “Right, ‘booth design & setup’ fits in nicely there. Florian, please add it.”
(Florian creates “booth design & setup” as an Epic.)
Ben: “So that’s already four big areas:
Trade show scheduling
Organization & bookings
Booth staffing & duty plan
Booth design & setup
Are you missing anything?
(The team thinks for a moment, but no one comes up with another suggestion.)
Ben: “Okay, this is already looking really good. But I'd change the order. 'Organization & Bookings' should come first, then 'Booth Design & Setup.' 'Scheduling' comes next, and only at the end 'Booth Staffing' – all nicely in the order we'll tackle each thing.
(Florian drags & drops the epics in the tree view.)
Before we go on, an important point: we keep running into things that are so big, they're almost like their own projects. In those cases, it can make sense not just to create an epic, but a dedicated component – basically a separate kit that we can reuse every year.
Katja: “Yeah, the brochure comes to mind right away. Last year that was a massive project – with the texts, design, printer, approvals.”
Ben: “Exactly, that's a great example. We probably do a brochure like that every year – and every time we ask ourselves again how we did it the last time. That's the perfect candidate for its own component.”
Florian: “So not an epic, but set it up as a separate component, right?”
Ben: “Right. Florian, please add it under ‘Brochure Trade Fair’. There we can include the usual steps like text, design, proofreading, printing – and next year we can just use it again.”
(Florian creates the “Create Brochure” component.)
Ben: “Awesome. That gives us the big picture: A ‘Trade Fair Appearance’ component with 4 epics for the main areas ‘Organization’, ‘Booth Design’, ‘Appointments’, and ‘Booth Support’. Also, a second component for creating a brochure. We'll leave that empty for now, since that would go too far. Today, we'll just focus on the trade fair appearance itself.”.
Lena: “That already brings a bit of structure in.”
Go to Administration → Component Library in the menu on the left.
Click Add Component at the top right.
A dialog window will open. Fill out the following fields:
Icon: Choose a fitting icon so it's easier to recognize this component at a glance.
Name: Enter a precise name for the component.
Description: Describe what this component is for. What should it be used for?
Tags: Tags make it easier to assign tickets later. Tip: Use a simplified version of the component name as the tag.
Internal note: Leave internal notes or instructions here for anyone who'll work with the component later. For example: special dates or important project steps.
Click Save.
Select the newly created component in the overview.
Switch to the tree view (default view for further work).
Click on the plus icon to add building blocks to the component.
Building blocks of project components
Select Create epic.
Fill out the fields:
Icon: Optional, helps you tell things apart visually.
Name: Name for the workspace or phase, e.g. “Design phase”.
Description: Explain the content, the WHAT of the epic.
Tags: Use a tag that you’ll also use later for all related work packages, checklists, or tests.
Internal note: Add an implementation guide for the team who’ll work on this epic later. The point is to describe the HOW.
Save the epic.
Epics and later other building blocks can be rearranged in the tree view via Drag & Drop.
Make sure the order of the elements matches the actual project workflow.
If the meeting already determined that more components are needed (like “Brochure creation”), add them right away in the same way.
That wraps up the first phase — the structure of the component is done and the first epics are set up.
Next up: specific work packages, checklists, and tests.
The team keeps going. Now, the concrete work packages for the “Organization & Bookings” epic are about to be worked out. The vibe is productive, everyone is focused. Florian projects the lead time input window for work packages onto the wall.
Ben: “Alright, let's go through the individual work packages now. Last time, we already talked about booking the booth area, getting booth equipment, booking a hotel, booking a van, and the kickoff meeting. Now it's all about actually creating the packages – and this time we're making sure to properly fill in all the fields. We need this info not just for carrying out the tasks, but also for our planning and budgeting.”
Florian: “I'll explain this again real quick, so we're all on the same page. For each work package, you need to fill in these fields:
Description: Here you write down WHAT is supposed to be done in this package – basically, the task itself.
Tags: The tags of the epic are inherited automatically, e.g., I‘ve given the whole component the tag ‘messe’ and the first epic the tag ‘messe_orga’. These tags get passed to all elements inside the work package. Later, when we create tickets from these work packages, it’ll give us more overview. You don't have to give the work package another tag, but it could make sense for our workflow.
Internal note: This is the one people often forget. Here, please explain the HOW – so basically, instructions for the person working on the package later. When someone gets the package, they should know right away how to go about the task without having to ask.
Minimum effort: And that's really important now…
Ben: “Exactly, the minimum effort! I want you to estimate for each work package how many hours you’ll need to get it done. We need these estimates for two reasons:
So I can budget the project better in advance – like, how much work we’ll actually have overall.
So later during controlling we can see if we stayed on track, or if something’s going wrong.
Lena: “So that means, now we’re gonna roughly estimate the hours for each work package?”
Ben: “Yeah, it doesn’t need to be rocket science. Better to estimate too many hours than too few. If you think 'book hotel' will take two hours, just put down two. If it turns out it’s just one – that’s fine too. But we need some kind of basis.”
Laura: “And what if we can’t estimate a package very well?”
Ben: “Then better to estimate more than too little. And if in doubt, let’s ask someone who’s done this kind of thing before.”
Florian: “So to sum up
Description = WHAT needs to be done
Tags are for structure
Internal note = HOW should the topic be tackled
and minimum effort = How many hours will this step take.
Can we pull this off?“
Team (nods in agreement): “Yes!”
Ben: “Alright, let's go. We'll tackle each work package one by one now.”
The team starts with “Book booth space”.
Lena: “So, that means we reserve the booth space with the trade show company. I know how that works, I do it every year. I'd say, if we go with the same offer as last year, with coordination and a few emails, it'll probably take about two hours.”
Florian: “Okay, I'll note it down:
Description: Reservation of the booth space with the trade fair company, clarifying the placement and size.
Tags are already there.
Internal note: Please check if the same booth space as last year is available. If not, ask for alternatives.
Minimum effort: 2 hours.
Ben: "Perfect, go on."
Katja: "Get booth equipment, that's the furniture thing and tech. I need to get the quote from the stand builder and maybe rent something else. That's hard to say. If we don't change anything, it takes three hours. If we decide to design a new booth, then we're really opening a huge can of worms."
Ben: "Maybe we can make a new component for that later. But this says minimum effort, so let's put in the three hours, because that's what it'll take – even if we just use everything from last year again."
Florian: "Okay, I'll write:
Description: Getting quotes for booth furniture and technical equipment, ordering after coordination.
Tags are here.
Internal note: Please ask the booth builder about standard packages first, then check options for special requests.
Minimum effort: 3 hours.”
Ben: “Great, go on.”
Laura: “I'll book the hotel again. I'll call the hotels we know and see if we can get something close again. I'd also say, two hours.”
Florian: “So: Description: Research and booking of hotel rooms for the whole team. Tags are here. Internal note: Ask our regular hotels first, then check alternatives within a max. 2 km radius.
Minimum effort: 2 hours.”
Laura: “Could we maybe put the contact details for the hotels right here in the description text? That would be handy.”
Ben: “Yeah, sure. Please add to these work packages any info that could help you with the work. You can also upload any order forms or other files to these work packages.
Florian: "Alright, and transporter?"
Lena: "I can do that too. I'll rent as usual from our rental guy. I'd say, about an hour."
Florian: "So:"
Description: Renting a transporter for booth setup and material transport.
Tags are there.
Internal note: Reserve the transporter at least a week in advance, coordinate pick-up and drop-off with the team.
Minimum effort: 1 hour.”
Ben: "So, now we’ve got the main booking topics covered. But there’s one thing I just thought about: When and how do we actually make these decisions? Last year it was often like this: We discussed forever, until someone finally took care of it."
Johannes Klein: "True, we lost weeks sometimes, just because it wasn’t clear who does what."
Ben: "That’s why my suggestion: At the start of each trade show project, let’s set up a kickoff meeting, where we talk about exactly these topics. We figure out right there: Which space do we want? Which hotel? Do we need a transporter? And then we divvy up the tasks."
Lena: "That makes sense. Otherwise, we'll get sidetracked again."
Ben: "Florian, please add another task for organizing the kickoff meeting."
Florian: "So:
Description: Planning and running the kickoff meeting for the trade fair prep.
Tags are there.
Internal note: Prepare the agenda (booth space, equipment, hotel, transport, staff),
Clarify responsibilities.
Minimum effort?"
Ben: "Hm. That's tricky. The meeting will probably take two hours or something like that. But if 5 people are in the meeting, it's actually 10 hours."
Florian: "We can solve that with a multiplier. I'll explain that to you later. For now, let's just enter a minimum value here, like how long it would take one person. So hours."
Laura: “I just thought of something: Wouldn’t it be good if we had a checklist before the kickoff so we know what we should clarify in advance?”
Ben: “Good idea.”
Florian: “There’s a special work package called ‘Checklist’ for things like this. It’s kind of like a ticket, except it contains lots of small tasks that need to be done:
Description: Prepping the kickoff meeting.
Tags are there.
Internal note: Compare the list with the insights from past years, check in with Ben.
Minimum effort: 1 hour.
I’d move the checklist and the kickoff meeting right to the very top above all the other work packages now, since these are the things we want to take care of first anyway. There you go.”
Ben: “Perfect, then we’ve got it. That seals our epic.”
After setting up the basic structure of the component in the first phase, it's now about creating the concrete work packages and checklists within the first epic “Organisation & Bookings”.
The building blocks of project components
In the component’s tree view, click the plus symbol in the row “Organisation & Bookings”.
A context menu pops up with three options:
Create acceptance test
Create checklist
Create work package
Select “Create work package”.
A dialog window opens with the following fields:
Icon: Optional symbol for visual labeling.
Name: Title of the work package, e.g. “Book booth space”.
Description: Task explanation, e.g.“Reserve the booth space with the event organizer, clarify placement and size”.
Tags: Optional, but will automatically be inherited from Epic and component.
Internal note: Notes for execution, e.g.“Please check if the same booth space as last year is available. If not, ask for alternatives.”
Minimum effort: Estimated minimum effort in hours, e.g. “2”.
"Save" click.
Just like the first task, add more work packages:
"Get trade fair equipment"(Add description and minimum effort as needed)
"Book van"
"Organize kickoff meeting"
In the same context menu "Create checklist" select.
Define a title and individual checklist items (todos).
Example: "Kickoff meeting prep" with tasks like:
Create agenda
Invite participants
Check tech
The newly created work packages and the checklist can be rearranged in the component tree using drag & drop.
In this example, the "Kickoff meeting" and its checklist were moved to the top since they're the first things to do.
Ben: Alright, let’s go even deeper into the details. We’ve defined our epics and set up the work packages – now it’s about spelling out the tasks inside those packages. We’ll start with “Kickoff prep.” Laura, what do we need for that?
Laura: So, we need to make sure up front that we’ve gathered all the important points for the kickoff meeting. So we don’t forget anything, we should make a checklist with the prep tasks.
Florian: Exactly. I’ll quickly show you how it works. We can set up so-called to-dos for the checklist. They’re made for small, clear tasks you can just tick off so everything runs smoothly during prep.
(Florian opens the “Kickoff prep” checklist in Leadtime and shows the input screen for to-dos.)
Florian Bauer: You see, we can just jot down the tasks here as a list.
(The team workshops a bunch of to-dos for the checklist.)
Set up kickoff meeting date: Find a suitable date for the kickoff meeting based on everyone's availability and send out the calendar invite to all participants.
Prepare meeting room: Reserve a suitable meeting room. Check if the room size is enough for all attendees and if equipment like projector and whiteboard are available. Before the kickoff, test the presentation setup in the reserved room (projector, laptop connection, WiFi, speakers). Report any issues right away and arrange alternatives if needed.
Collect current trade fair documents: Gather all relevant documents for the event (floor plans, organizer info, booking guidelines, cost overview) from the event website or from last year and store in a shared folder.
Get budget guidelines from Ben: Have a quick check-in with Ben Heinrich to clarify the max budget for event planning. Write down which cost items to especially keep an eye on.
Review relevant docs from last year: Go through reports, notes, and lessons learned from last year's event and see what insights might help for this year's planning.
Set up project in Leadtime: Create the new event project in Leadtime, load the component, and add the responsible teams.
(Florian is typing in the points.)
Ben: Perfect. We can just work through the points one by one. And what about the work packages themselves?
Florian: Those are already in place. Let's take the “Kickoff-Meeting.” Every work package in Leadtime has a form that we can attach. I'll quickly explain why that's important.
(Florian opens the work package “Kickoff-Meeting.”)
Florian: In the description of the work package, you'll find the “what” – so, what needs to be done. The “Internal Note,” on the other hand, is like an instruction for the person doing the task, so the “how.” But: For the person to really get the task done, the requirements have to be clear. That's exactly what the form is for.
Ben: The thing is: Every time we do a project like this, the situation is a little different: Different people are involved, maybe we want to bring a different booth or try out a new presentation concept. With the form questions, we can pretty much customize the work package to the specific situation.
Florian: Exactly. And the questions for this first action package could help us talk about the right topics at the kickoff meeting. You just go through the points in the meeting and fill in the answers straight into the form. And the answers also affect the other work packages.
Ben: Awesome. Let's collect the questions for the kickoff meeting.
(The team comes up with the questions together.)
Who is in charge of the project?
Question type: Person
Description: Responsible for managing the entire trade show project.
Florian: “Person” is a special question type. That way, you can pick someone from our team directly. Super handy, because that person will show up later as the responsible one for related tasks. And it’s always clear who’s really in charge.
Which team members are going to the trade show?
Question type: Person
Description: Select the people who will be at the booth on site.
Florian: Here we’re using “Person” again. You can pick several people, for example everyone who’ll be at the booth. It’s way clearer than just writing names in the text.
Is a new trade show booth needed?
Question type: Radio button (Yes/No)
Description: Clarify whether a new booth model needs to be developed or if the existing one can be used.
Florian: We can use this question later for a condition.
Katja: What's a condition?
Florian: Work packages can be shown or hidden based on specific answers. Let’s take the question "Do we need a new trade show booth?" as an example. If this is answered with "No", we can set a condition so that the work package "Design a new trade show booth" is automatically hidden. Katja: Cool, so that means the structure of the project automatically adapts to our answers?
Florian: Yeah baby, you got it. Let’s keep going
Who organizes the hotel bookings?
Question type: Person
Description: Specify the responsible person.
Who takes care of the booth design?
Question type: Person
Description: Define the responsible person.
How many people take part in the kickoff meeting?
Question type: Multiplier
Description: Set the number of participants. Duration per person: 2 hours.
Florian: The multiplier is especially useful when the duration of a task depends on how many people are involved. For example: The kickoff meeting lasts 2 hours per person. So if we enter 5 people here in the form, Leadtime automatically calculates 5 times 2 hours, so 10 hours of effort. That’s super helpful for later scheduling and budgeting.
(The team continues)
Which delivery dates do we have to keep in mind?
Question type: Short text
Description: Relevant deadlines for booth construction, print materials, etc.
Is there a current order form from the trade fair company?
Question type: File upload
Description: If available, please upload.
Who will handle transport organization?
Question type: Person
Description: Assign the person responsible for booking vehicles and handling logistics.
How do we secure our trade fair booth?
Question type: Radiobuttons
Description: In the past, there have been minor damages to our booth at night. How can we make sure this doesn't happen?
Options: Stand guard, camera monitoring, no guard
Ben: Perfect. That’s exactly the structure we need so we don’t have to start from scratch every year.
Florian: And don’t forget: this form principle applies to all work packages. For each package, think about which questions the execution should clarify so you don’t need to ask anything later.
Ben Heinrich: Alright, then let’s get on with the other packages. Or do you guys need a little break?
Now it’s about adding forms to the work packages and checklists you’ve already set up. These forms help to flexibly adapt the work packages to the project’s specific situation.
In our sample project, the starting situation changes from year to year—for example, different people take part in the fair, or a new booth has to be built. The form questions help you tailor the work packages to the specific, current situation.
Checklists are made up of individual tasks that have to be completed one after the other.
Here’s how it works:
In the components tree, select the checklist (e.g. "Kick-off preparation").
Click the "Add To-Do" button in the middle.
A dialog box will open:
Enter the To-Do title (e.g. "Set kick-off date").
Optional: Add a description.
Save.
The To-Do now shows up in the checklist and can be checked off while working on the project.
Questions let you adapt a work package flexibly to the specific project situation.
Here's how:
Select the work package in the component tree (e.g. "Kick-off meeting").
Click on “Add question”.
A dialog box will open:
Title: Short name for the question (e.g. "Project lead").
Question: Full wording of the question (e.g. "Who is taking on the project lead?").
Description: Explanation for the question (e.g. "Responsible for managing the entire trade fair project.").
Question type: Select the right question type (e.g. "Person").
Save.
The question is added to the work package and will be filled out when the project starts later.
The question type Multiplier affects the effort estimation of the work package:
• Example: Question “How many people will take part in the kick-off meeting?”
• The question states that 2 hours per person are planned.
• If the user later enters “5 people”, the effort is automatically set to 10 hours.
The order of the questions can be changed via drag & drop. For example, the question about the number of participants often makes sense at the beginning.
After a long and intense workshop, interrupted by several breaks, the team has now created the work packages for all epics and added forms. During the process, new ideas kept popping up, so Florian adjusted and expanded the component tree multiple times. Additional epics and work packages were created or existing ones were merged. Florian points out that all elements in the component tree can be moved via drag & drop. It's even possible to move a question from one work package to another. Now, in the late afternoon, everyone is a little tired, but happy. It's a great feeling to have built a long-lasting solution for a demanding project that comes up every year.
Florian: "Alright, final sprint! Now that the structure is pretty much done, let's look at the topic of conditions. I put this off all day because it's just better to do this when you can see the whole project in front of you."
Florian explains again what conditions are: "With conditions, we can make sure that certain questions or work packages only show up if a previous answer meets a specific condition. This way, the component stays clear and always shows just the relevant tasks."
For the first practical example, the team opens the work package "Get trade fair booth equipment." They're going to add a condition there:
Question: "Do we need booth security?" (with Yes/No as answer options)
Follow-up question: "Please book booth security and upload the order form" – this should only show up if the first question was answered with "Yes."
Plus, if it's a "Yes," the minimum effort increases by 2 hours.
The second example is about the work package "Booth support & duty roster." Here, the question "Do we need new business cards?" is added. If this is answered with "Yes," the work package "Order business cards" should pop up automatically.
The team adds more conditions in various packages.
Ben: "Anyone else got an idea?"
Johannes: "Yeah, at last year's fair we forgot a thousand things. I had to go to the hardware store three times. Can't we make a checklist for the packing plan?"
Florian: "Good idea! Even better: We could set up an acceptance test instead. That's more accurate than a simple checklist. Acceptance tests actually come from software development. They're a bit more flexible."
Florian explains:
Acceptance tests are made of:
Title
Description
Steps
Expected result
During the acceptance, the tester can say: "Works" or "Doesn't work" and in the second case can leave a comment.
If "Doesn't work" is chosen, a ticket to fix the problem can be created right away.
Katja: “Cool, we can totally use this for our software projects too!”
The team is coming up with the first test cases for the packaging plan together. Florian shows the test case “Toolbox” as an example:
Title: Toolbox
Description: “Please check if the toolbox is stowed away. Specifically, it should include:”
Steps:
Open the toolbox
Check the contents
Expected result: “Screwdriver, hammer, and duct tape are there”
Ben: “Let’s create one last task package called “Lessons Learned Meeting”. After the trade fair, we’ll take the time to write down together what went well and what didn’t. Then we’ll revise the project component – the effort estimates as well as the content, if needed.”
Everyone agrees and thinks it’s a really good idea.
Ben wraps up the session: “When the project officially starts, please update the work packages in the component library with more info if needed – whatever makes things easier for you.”
In the final phase of creating a component, it's all about refining the project's structure. You do this by adding conditions that only show certain work packages, questions or acceptance tests if a set condition has been met earlier.
The goal here is to make the project easier to fill out later by keeping things simple. Any unnecessary work packages or questions are automatically hidden, so you only see what's needed for that specific project.
When does this phase make sense?
It's best to start refining once the basic structure of the component is in place and you’ve defined most epics and work packages. With conditions, you can then turn certain branches of the component tree on or off as you need.
Let's say in the work package “Kickoff Meeting” there’s this question: How do we secure our booth?
Answer options (radio button):
No security
Security guard
Camera monitoring
In the logistics epic, there’s a work package that should only be active if it was decided in the kickoff meeting that there will be a security guard.
In the epic "Trade Fair Planning & Logistics", create a new work package "Organize security guard".
Add condition:
Component: Trade Fair Planning
Element: Kickoff Meeting
Target: Question "Security"
Condition type: Answer contains "Security guard"
Save
Acceptance tests are a special kind of work package. They work a bit like checklists, but with detailed test steps and expected results.
An acceptance test defines:
The test title
Description of the scope
Concrete steps for execution
Expected result
A tester checks the requirements and documents the result.
If a test fails, you can directly create a new ticket to fix the issue.
