Checking in with stuff is a big part of management, collaborating, achieving goals and operating an organization in general.
Nearly all teams develop some sort of check-in scheduele over time to ensure that things run smoothly.
Check-ins help us:
Some check-in patterns that commonly develop in teams over time are:
Commonly, check-ins are organized as meetings amongst team members. This may or may not result in an effective check-in.
It all depends on whether:
To help alleviate these potential pitfalls, the platform supports health checks.
Health checks allow you to organize and share your thinking around who should check in with what, why, at which intervals and how. Health checks also allow you and your team to log actual check-ins with a health check, making it easier to share the information uncovered, agreements made, as well as ensuring that the health checks are actually being conducted.
Each health check is broken down into perspectives. Perspectives are the different aspects you want to look at when checking the health of something.
For instance, if the focus of a health check is projects, some relevant perspectives might include:
For each perspective, you can share insight around which data to review and which questions to ask in order to best evaluate the perspective.
Policies are a great way of sharing and aligning preferred team behaviour.
A policy consists of
In order to add a new policy, use the quick create functionality or navigate to the relevant team, select Policies and click the green plus icon.
Policies can be categorized in order to group similar policies together. Policies are grouped by their categories when displayed in the context of the team.
Linking policies to roles help ensure that people remain familiar with relevant behavioural expectations as the organization grows and policies adapt.
Linking a policy to a role is what ensures that the policy appears in the training view for that role.
A policy can have one of the the following states:
The current stat of the policy is displayed to the right of the policy title.
Sjekklister er den etablerte/offisielle måten å gjøre noe på.
Sjekklister knyttes til et team og består av et hierarki av deloppgaver som kan påføres nye eller eksisterende oppgaver.
Teamets sjekklister er som et utgangspunkt kun tilgjengelig for brukere som har tilgang til teamet.
Unntaket er dersom du har valgt å Gjøre en sjekkliste tilgjengelig i biblioteket.
You may use the quick create functionality or navigate to the relevant team, select Checklist in the left menu and click the green plus icon in the up-right corner.
Oppretting av nye oppgaver i en sjekkliste fungerer på samme måte som oppretting av nye deloppgaver.
Du kan endre en oppgaves plassering i oppgavehierarkiet ved å dra og slippe oppgaven til ønsket plassering. Dersom du ønsker å plassere en oppgave dypere i oppgavehierarkiet, klikk på tallet som indikerer antallet underlagte oppgaver for å å åpne opp det relevante hierarkiet.
Vi kaller informasjon om oppgaver i sjekklister for meta data. Meta data er informasjon du ønsker at enten skal kopieres inn i oppgaven når sjekklisten opprettes, eller på en annen måte hensyntas når sjekklisten påføres.
Oppgaver i sjekklister støtter følgende typer metadata:
Personen du ønsker skal tildeles oppgaven når sjekklisten påføres.
En beskrivelse du ønsker kopiert inn som oppgavebeskrivelse når sjekklisten påføres.
Signalisering av at en oppgave er blokkert av en annen. Når sjekklisten påføres vil blokkerne knyttes mellom oppgavene som opprettes.
Et etimat du ønsker kopiert inn som oppgave estimat når sjekklisten påføres.
Signalisering av at en oppgave har en frist. Når sjekklisten påføres vil du bli bedt om å angi de konkrete fristene for oppgavene.
Signalisering av at en oppgave skal innlemme en annen, frittstående sjekkliste. Når sjekklisten påføres vil den frittstående sjekklisten kopieres inn på rett plass i oppgavetreet.
Etter du har redigert eksisterende metadata vil du bli spurt om du ønsker at endringene skal forplantes til åpne oppgaver.
Når du legger til eller endrer metadata vil du, dersom det finnes åpne oppgaver basert på sjekklisten, bli spurt om du ønsker å oppdatere disse oppgavene med sjekkliste-endringene.
Det er støtte for å forplante følgende typer meta-endringer:
Du bruker en sjekkliste ved å påføre den på et prosjekt eller en oppgave.
En påføring vil si at sjekklisten brukes som mal for å opprette et oppgave-tre hvor det er mulig å kommentere, føre fremdrift, logge tid og skape annen sporbarhet i gjennomføringen av arbeidet.
Du kan påføre sjekklister på forskjellige måter på forskjellige steder:
Dersom sjekklisten som påføres har oppgaver med meta data som krever input vil denne inputen bli etterspurt når du påfører sjekklisten.
Følgende meta data krever input:
En prosdyre kan innlemme andre sjekklister.
Dersom en av sjekklistene som er innlemmet mangler på påføringstidspunktet vil du bli varslet om dette slik at du kan velge om du ønsker å opprette/kopiere inn sjekklisten, eller fortsette påføringen uten den innlemmede sjekklisten.
Det er mulig å eksportere punktene i en sjekkliste til en issue i den utbredte issue trackeren Jira.
Eksporten oppretter deloppgavene i sjekklisten som subtasks i Jira, med e-postadressen til den innloggede brukeren i NM Project som reporter.
Ettersom Jira ikke støtter et hierarki av subtasks vil sjekklister bestående av et hierarki som et utgangspunkt innlemmes deloppgaver på nivå 2 og dypere som oppgavebeskrivelser.
Krysser du imidlertid av for "Lag deloppgaver på alle nivåer" så ville alle deloppgaver i hele hierarkiet konverteres til en flat deloppgavestruktur.
Eksempelvis vil følgende sjekkliste
Mor
Barn 1
Barn 2
...importeres inn som følgende to subtasks:
For å kunne eksportere sjekklister til en Jira issue må du sette opp et eller flere Jira prosjekter. Det finnes i dag inget grafisk grensesnitt for å legge til Jira prosjekter. De må redigeres direkte i databasen, i tabellen JiraProject.
For team med mange sjekklister kan du kategorisere disse. Sjekklistene vil grupperes på kategoriene på teamets liste over sjekklister.
For å kategorisere en sjekkliste, gå inn på sjekklisten og trykk på "Legg til kategori".
Skriv inn ønsket kategori-navn og trykk på Legg til. Dersom du har lagt til kategorier tidligere vil det å begynne å skrive et kategorinavn søke blant disse.
I høyre kolonne, under deloverskriften "Påføringer", kan du se hvor, når og av hvem sjekklisten har blitt påført.
Du kan også klikke deg videre ut til prosjektet eller oppgaven sjekklisten har blitt påført om du ønsker å studere nærmere hvordan arbeidet har blitt gjort.
Sjekklistene er organisert i grupper basert på hva de er tagget med. Sjekklister uten tags vises først.
Bruk det globale søket for å søke opp sjekklisten ved navn.
Du kan flytte en sjekkliste til et annet team ved å trykke på ikonet av et hus i tilknytning til brødsmulestien, eller ved å nyttegjøre tastatursnarveien Cmd + Shift + P.
Dette vil utløse en modalboks hvor du kan søke opp teamet du ønsker å flytte sjekklisten til.
En sjekkliste kan ha forskjellige tilstander som gjenspeiler forventningene til sjekklistens bruk. De alternative tilstandene er:
Nye sjekklister som opprettes får automatisk tilstanden "Utkast". Det er kun sjekklister med tilstanden "Aktiv" som forventes nyttegjort. Når sjekklister ikke lenger er i bruk settes de til tilstanden "Arkivert".
For å endre en sjekklistens tilstand, klikk på pilen som peker ned ved siden av tilstandsangivelsen i toppen av sjekklisten i fullvisning og velg en ny tilstand.
Du kan kopiere sjekklister du har tilgang til å se. Et use case for å kopiere en sjekkliste er dersom en annen organisasjon som bruker Wecomplish har en sjekkliste som du ønsker å kopiere til et av dine egne team.
For en nærmere forklaring, se Dele innhold på tvers av organisasjoner.
Dersom du ønsker å dele en sjekkliste med andre utenfor din organisasjon kan du gjøre den tilgjengelig i Dele innhold på tvers av organisasjoner.
For å gjøre sjekklisten tilgjengelig og søkbar i biblioteket, rediger sjekklisten og kryss av for "Offentlig tilgjengelig" og velg en kategori som sjekklisten skal presenteres under i listen "Offentlig kategori".
The platform allows you to create a wiki for a team or a project in the form of pages organized in a hierarchy with associated Kommentarer. The pages support rich formatting, familiarity and are searchable in the global search.
By default, the wiki is only accessible to logged in users who have access to the team or project with which the wiki is associated.
However, by editing the team and checking the "Make wiki publicly available" option, the wiki is made available to anyone on the internet, without having to log in.
Look for this indicator to see if the wiki page you're currently working on is a part of a publicly available wiki:
For å endre rekkefølgen på sider, dra og slipp sidene i ønsket rekkefølge. Du kan kun endre rekkefølgen på sider underlagt siden du befinner deg på.
For å endre en sides plassering, trykk de tre prikkene øverst til høyre og velg "Flytt".
En sides forelder kan være et team, et prosjekt eller en annen side.
Dersom du ønsker å motta varsel om endringer i et teams wiki må du abonnere på dette.
For å opprette et abonnement, naviger deg fram til den delen av wiki-en du ønsker å bli varslet om endringer for og trykk på knappen "Varsle meg om endringer" i høyre kolonne.
Når du har aktivert varsling endres knappen til "Ikke varsle om endringer". Trykk på denne om du ønsker å skru av abonnementet igjen.
Et abonnement gjelder for siden du abonnerer på (direkte abonnement) og alle underlagte sider (indirekte abonnement).
Det betyr at et abonnementet du oppretter på wiki-forsiden vil resulterte i et indirekte abonnement på hele teamets wiki, mens et abonnement opprettet på en konkret side kun vil resultere i indirekte abonnement på sider underlagt denne.
Ansatte kan, i tillegg til å styre eget abonnement, legge til og fjerne andres abonnement på wiki-en.
Administrasjon av abonnementer gjøres ved å trykke på teksten i høyre kolonne som viser hvor mange som abonnerer på denne delen av wiki-en.
Fra dette vinduet kan du legge til nye abonnenter og fjerne direkte abonnement. For indirekte abonnement gjengis det en lenke til hvor det direkte abonnementet har sin opprinnelse.
For å varsle om en endring i wiki-en, kryss av for "Varsle om endringen" når siden redigeres. Dette vil sende ut en e-post om tekstendringene på siden til alle med direkte og indirekte abonnement på siden. Trykk på teksten som viser hvor mange som varsles om endringer for å se de konkrete personene som vil motta varsel.
Om du også fyller ut feltet "Motivasjonen bak dokumentasjonsendringen" vil denne forklaringen inkluderes i e-postvarselet. Feltet støtter Rik formatering.
Ved opprettelse av en side har du muligheten til å velge en mal som siden skal kopiere innhold og eventuelle underlagte sider fra.
Les mer om Maler.
There are multiple places where you can upload images and other types of attachments which can then be embedded into rich text areas.
These are the insight types that can be assigned attachments. In addition, attachments can be added to comments on tasks and observations.
Press the button or link labeled "Upload attachment". Select the attachments you want to upload by clicking the "Browse" link, or by dragging and dropping the relevant files to the upload area.
Then, click the "Upload x file" button in order to actually trigger the upload. When you are done, you can close the upload widget by clicking the cross in the top, right corner.
Med maler kan teamet definere utgangspunkt for enkeltsider og hele hierarkier av dokumentasjon slik at teamet kan spare tid og tydeliggjøre forventningene til hvordan noe forventes dokumentert.
En mal kan ha et innhold og x antall undersider ordnet i er uendelig hierarki.
En underside kan innlemme andre maler slik at én mal kan gjenbrukes på tvers av flere maler, uten at innholdet må vedlikeholdes flere steder.
For å opprette en mal, gå til teamet, velg Maler i navigasjonen og trykk "Ny mal".
Teamets maler er som et utgangspunkt kun tilgjengelig for brukere som har tilgang til teamet.
Unntaket er dersom du har valgt å Gjøre en mal offentlig tilgjengelig.
Du kan kopiere maler du har tilgang til å se. Et use case for å kopiere en mal er dersom en annen organisasjon som bruker Wecomplish har en mal som du ønsker å kopiere og tilpasse for et av dine egne team.
For å kopiere en mal, velg "Kopier" i listen over handlinger tilknyttet en mal. Du vil så få velge hvilken organisasjon og hvilket team malen skal kopieres til.
Dersom du ønsker å dele en mal med andre utenfor din organisasjon kan du gjøre den offentlig tilgjengelig.
For å gjøre malen tilgjengelig, rediger malen og kryss av for "Offentlig tilgjengelig".
Processes are a great way to describe what a team or an organization is expected to be able to do, and which resources are required to complete each step in the process.
A process consists of a tree of process steps, tied together with optional conditions, to form a complete process.
Each process step can be associated with the resources relevant to complete that step, be it roles, systems, checklists, policies, risks, etc.
In addition to their ability to communicate how something is done, the process implementation in the platform is also tactical, meaning processes can be applied across projects and tasks.
When you want to utilize a process, you can apply it to a project or a task.
Applying the process provides multiple benefits, including:
To apply a process, navigate to the process and click the green plus icon in relation to the Applications heading.
Applying a process brings you to the step selector. Here you decide which of the available steps to apply, and where to apply it.
When triggering a process application the initial process step is the only option, and you are prompted to select a location (project or task) to which the process should be applied.
After selecting a step, you will be asked to select the next step, and so on, until the process is completed.
When selecting additional steps after the first one, you can decide if you want the next step applied to the same location as the previous step (this is the default option) or to a new location.
Use cases for applying a next step to a new location might include a big process spanning across multiple teams and projects (for instance a holistic process covering recruiting/onboarding or sales/manufacturing).
As you continue on selecting steps, the right column fills out with a navigation showing the steps selected so far.
You may select steps so long as you have the motivation and information required to decide on a next step.
If you come to a point where you want to await deciding on more steps, you may navigate away from the step selection and into the tasks applied using the navigation in the right colum indicating the steps applied so far.
To resume the step selection process, you can either click the "Select next step" button displayed on the task, or wait for the task to be marked as completed.
When completing a task created from a process step, and provided that there are remaining steps in the process, you will be automatically brought back to the step selector where you can choose the next step from the steps available.
If the step you choose to apply has checklists associated with it, you will be sent to the checklist applier. Here you decide which checklist (if any) you want to apply to the task representing the process step.
To view past applications of a process, navigate to the process in question and click the View button in relation to the application you want to examine.
The application view displays the list of steps applied so far, including their respective application locations.
The process steps of a process can be presented in different views. To change the view, select the desired view from the list of views to the right of the Steps header:
To change the default view of a particular process, edit the process and select the desired default view.
The available views are:
Lists process steps in a branched process map. The color of the process steps match the state of the process step. Double click a process step to view its details.
The process map is best suited for branched processes (meaning processes where a process steps has multiple next steps) as it visualizes the branching.
The process map is the default view, unless a different default view has been explicitly selected for the particular process.
Lists process steps as a list of steps, including step purposes and associated content. To make the expanded view the default view of a particular process, edit the process.
The expanded view is best suited for linear processes (meaning processes where all the process steps only have one next step) as it does not visualize any branching.