Project Handbook

How ProsessPilotene delivers projects. The methodology, roles, and checklists that ensure the right deliverables, on time and to the right standard, in every project.

The best projects are created when customer and supplier work well together and take complementary roles in one delivery team. This handbook shows how ProsessPilotene makes that possible — from the first enquiry to the delivered solution.

This page summarises the project handbook for customers and employees. As a customer, it shows you what to expect from us — and what we will expect from you.

Project management office

The project management office (PMO) owns the delivery methodology and has overall responsibility for every project ProsessPilotene undertakes.

Good delivery is defined by ProsessPilotene's quality system: the right delivery, at the right time and quality. To ensure this, the management team has established a Project Management Office that brings together all the rules and methods ProsessPilotene uses in the project handbook.

The project management office is led by a project director and draws on project managers across the organisation. The handbook is continually revised based on feedback from customers and employees, and all changes are formally approved by the management team.

The project handbook is public and can be shared with customers — it belongs to ProsessPilotene, and this page presents its content in brief.

The purpose of the project management office

Strengthen project management as a discipline at ProsessPilotene
Establish consistent methods and ways of working across all deliveries
Ensure quality, progress and control in every project
Manage risk across the entire project portfolio
Coordinate reporting of key figures from all projects
Enable growth and larger projects

Delivery methodology

Four phases from enquiry to application management. The project process takes over where the sales process ends, and concludes where application management begins.

Sales
Process owner: Head of sales
The sales process establishes the basis for the project: a work package describing the project and, for larger deliveries, a high-level solution description and a roadmap. The aim is a shared foundation understood by both the customer and those responsible for delivery.
The phase is complete when
Signed work package and approved project plan. Responsibility transfers from the KAM to the project manager.
Key activities · 7
- Register and qualify the enquiry
  KAM
- Prepare the work package — background, objectives and value creation
  KAM
- Detailed list of deliverables with estimates
  Solution lead
- Advice on architecture, testing and training strategy
  Enterprise architect, test manager and training lead
- Project planning: WBS, RBS and schedule
  Project manager and solution lead
- Agree the plan and budget, sign the work package
  Customer and KAM
- Tentative resource bookings become confirmed bookings on approval
  KAM
Initiation
Process owner: Project manager
Initiation builds commitment among all project participants. This phase often takes four weeks — time well spent: the foundations laid here determine how efficiently the project will be delivered.
The phase is complete when
Everyone knows why the project exists, what will be delivered and what their role is. Approval by the project team or steering committee starts delivery.
Key activities · 7
- Allocate and mobilise resources with clear roles and scope
  KAM and project manager
- Review the work package, plan, strategies and estimates — catch mistakes early
  Entire project team
- Establish strategies for information architecture, integrations, testing, data migration and training
  The project manager leads the work
- Set up Azure DevOps: WBS, user stories, test plan and training tasks
  Project manager, solution lead, test manager
- Plan the first sprint in detail and prepare the kickoff
  Project manager
- Hold the kickoff — demonstrate the project's benefits for the customer
  Project manager and customer
- Establish the meeting schedule, administrative procedures and development environment
  Project manager and CRM consultant
Delivery
Process owner: Project manager
The delivery phase fulfils the work package. ProsessPilotene uses Prince2 Agile for agile projects and Prince2 for waterfall projects. All work is documented in Azure DevOps, and time is recorded using 7Pace.
The phase is complete when
A delivery that meets the requirements in DevOps. Status is tracked using traffic-light KPIs for progress, scope, time, resources, risk, finances and objectives.
Key activities · 6
- Plan: define and estimate tasks in DevOps
  Customer and solution lead
- Design: specifications, process descriptions and UX in the WIKI
  Customer and solution lead
- Develop the solution in line with the requirements in DevOps
  CRM consultants
- Test your own deliverables and carry out customer acceptance tests
  CRM consultants, test manager and customer
- Roll out: demonstrate, deploy to production and train users
  Entire team and customer
- Evaluate each sprint with a retrospective
  Project manager
Closure
Process owner: Project manager
Closure brings the project to a controlled end: deliverables are approved, lessons are collected, and ownership transfers to application management.
The phase is complete when
The steering committee formally closes the project, the application management team takes ownership, and the customer continues working with their KAM.
Key activities · 7
- Prepare the final report and financial status
  Project manager and solution lead
- Update the list of known defects, issues and risks
  Solution lead
- Revise the backlog with suggested improvements for the customer
  Solution lead and project manager
- Demonstrate the result to the steering committee
  CRM consultant
- Hold a retrospective with the project team and evaluate the project with the customer
  Project manager and KAM
- Formally close the project at a steering committee meeting
  Customer
- Hand over to application management and release resources
  Project manager and KAM

How a sprint works

In agile projects, delivery is divided into sprints following a fixed pattern: plan, design, develop, test, roll out — and evaluate before the next round. The customer contributes needs and requests directly in DevOps, and each sprint ends with a retrospective.

Checklists

The handbook's most important practical tools: checklists for planning, delivery, closure and evaluation.

Planning

Ready for delivery

The objectives of the initiation phase — everything must be in place before delivery begins.

Show checklist · 8 items

Everyone understands why the project exists and what is to be delivered
Everyone understands their role, their delivery plan and what is out of scope
Everyone knows what they can expect from each other
Collaboration is agreed — communication, documentation and the use of DevOps
Strategies for testing, training, integrations and information architecture are agreed
Access to meeting rooms, technical environments, licences and passwords is arranged
The meeting schedule and calendar are established
The project plan is understood and the first sprint plan is ready

Delivery

The right quality throughout

Shared requirements for everyone on the project team throughout delivery.

Show checklist · 8 items

Every task is documented in DevOps with a precise title, category and estimate
Status, remaining time and completed time are kept up to date on your own tasks
Time is recorded weekly in Xledger — and in 7Pace when requested by the project manager
Deviations of more than 10% from an estimate are reported to the project manager
Deviations, concerns, issues and risks are reported proactively, directly and openly
Your own deliverables are unit tested and documented before handover
Checked-in code is always linked to the task in DevOps
Sprints follow the established routines: sprint planning, standups, project team and steering committee meetings

Closure

Controlled closure

The information required before the steering committee can close the project.

Show checklist · 8 items

Final report meeting the requirements of the work package
Financial report with the project's final status
Updated list of known defects and shortcomings
Updated issue list and risk matrix
Revised backlog in DevOps with recommendations for the customer
Evaluation from the project team and the customer
Demonstration completed for the steering committee
Handover to application management is agreed and completed

Evaluation

Retrospective

The retrospective after each sprint and at project closure — start, stop, continue.

Show checklist · 6 items

What went well in the sprint — and what did we do differently to achieve it?
What did not go to plan — without looking for someone to blame?
What did we learn that can improve how we work?
Which specific improvements will we take into the next sprint?
Is the definition of done still right for the team?
At project closure: the project team shares its knowledge across ProsessPilotene

Routine

The standup meeting

The standup keeps the team aligned — usually weekly, or daily during intensive periods. The meeting should be short enough to stand through, never more than 30 minutes. The project manager opens with news and changes in priorities; everyone then answers three questions in no more than three minutes.

Show checklist · 4 items

What have I achieved since last time?
What will I do next?
What obstacles are blocking my progress?
All updates from the meeting are recorded in DevOps

Delivery

Typical delivery contents

Standardised checklists used as the basis for user stories and tasks in DevOps.

Show checklist · 6 items

Developing a Dynamics 365 application
Developing a website
Developing an integration
Developing a web API
Developing a data warehouse
Related procedures: estimation, changes, issues, workshop facilitation and production deployment

Guides from the handbook

The checklists tell you WHAT to do — the guides below show you HOW, step by step.

All project management guides →

Roles

Eight defined roles with clear authority and responsibilities. The combination varies by project, but the key roles must always be filled.

Common to all roles

Whatever your role, you are expected to define and deliver your own tasks to the right quality, keep DevOps updated, record time weekly, report deviations of more than 10% from estimates — and be proactive, direct, open, honest and prepared.

Key Account Manager

ProsessPilotene's salesperson and the customer's adviser, with overall ownership of the customer relationship across active projects and ongoing application management.

Authority, responsibilities and skills

Commercial responsibility for the customer's long-term development and roadmap
Plans and runs sales processes, signs work packages
Responsible for customer satisfaction and profitability
Requests resources from the resource allocation group

Duration: Active for as long as the customer relationship lasts — without exception.
Skills: Level 200 — Salespeople

Project owner

The person with ultimate responsibility and final decision-making authority in a project or project portfolio. At ProsessPilotene, normally the same person as the KAM.

Authority, responsibilities and skills

Actively participates in steering committee meetings
Reads all reporting and stays informed about status and finances
Escalates deviations to ProsessPilotene's management team

Duration: Throughout the project, regardless of its size.
Skills: Level 200 — Salespeople

Project manager

Manages the project day to day and ensures the agreed deliverables meet the agreed quality within the time and cost limits.

Authority, responsibilities and skills

Planning, delegating, monitoring and controlling all aspects of the project
Project finances, resources and alignment of expectations between the parties
Reports risks, issues, changes and deviations — and escalates when necessary
Leads the steering committee and conducts retrospectives

Duration: From planning until the project is formally closed. Every delivery project must have a project manager.
Skills: Level 300 — Project managers

Enterprise architect

Advises on the bigger picture: information, application and technology support, based on the TOGAF framework.

Authority, responsibilities and skills

Designs information architecture at a system-neutral level
Advises on integration strategy, test strategy and information security
Acts as a sounding board for the solution lead on technology choices

Duration: Relevant in larger projects with demanding integrations, information models or complex business processes.
Skills: Level 200 — Architects · TOGAF 9 · Archimate 3

Solution lead

Owns the solution architecture and has operational responsibility for what is delivered — while the project manager owns when it is delivered.

Authority, responsibilities and skills

Identifies customer needs and specifies proposed solutions with estimates
Provides technical leadership for the specialists on the project team
Ensures documentation: process flows, data models and solution descriptions
Makes decisions on significant functional and technical choices

Duration: Every project must have a solution lead. After project closure, the customer dialogue returns to the KAM.
Skills: Level 200 — Solution leads

Test manager

Ensures that the solution meets the quality required by specifications and agreements. A dedicated role in large projects and projects with high risk.

Authority, responsibilities and skills

Prepares the test strategy, test plans and test tasks
Facilitates internal testing and the customer's acceptance tests
Bug triage: classifies and prioritises incoming defects
Carries out automated testing

Duration: Primarily during delivery. Has the authority to stop a production deployment if quality is inadequate.
Skills: Level 200 · ISO/IEC 29119 · DevOps Testing

Training lead

Responsible for user adoption: secures the customer's management support for the strategy, creates the training plan and delivers the training.

Authority, responsibilities and skills

Prepares the training strategy with objectives, target groups and methods
Plans and carries out the project's training activities
Ensures that the solution is adopted in line with best practices

Duration: Every large project must have a training lead, active until the delivery is approved.
Skills: Level 100 + teaching skills

CRM consultant

Adapts the solution to the customer's requirements — functionally (Dynamics 365), technically (programming) or analytically (insight, reporting and data warehousing).

Authority, responsibilities and skills

Delivers the tasks defined in the project plan and DevOps
Responsible for the quality and testing of their own deliverables
Keeps DevOps updated: estimates, categories, status and ownership
Reports deviations of more than 10% from an estimate

Duration: Active until the delivery is completed and approved, often across a series of deliveries for the same customer.
Skills: Level 100 + relevant product certification

Choosing a methodology

ProsessPilotene works with several methodologies — advice from the project management office determines which one suits the delivery.

Prince2 Agile
Preferred
The preferred methodology for most deliveries — adapted to each customer and project.
Kanban
Preferred for support and application management tasks, where work is governed by capacity and flow.
Scrum
Best suited to creating software from scratch, or to a team working without dedicated project management.
Waterfall
Can be used for small projects with clear requirements and little uncertainty.

For customers with several parallel projects and suppliers, ProsessPilotene bases portfolio management on SAFe (Scaled Agile Framework), with a steering committee, project team and working groups at strategic, tactical and team level.

Terms and estimation

Shared language creates shared expectations — the key terms and standard allowances that make estimates and budgets predictable.

Work package

The contract document defining the project: scope, cost, risk, quality and deliverables. The transition from sales to project delivery takes place when the work package is signed.

WBS

Work Breakdown Structure — the hierarchical breakdown of the delivery. ProsessPilotene uses four fixed levels, corresponding in DevOps to Epic, Feature, user story and task.

RBS

The Resource Breakdown Structure defines the roles the project needs, clarifies reporting lines and provides the basis for who owns what in DevOps.

Sprint

A defined period with its own deliverables, resource allocation and budget. At ProsessPilotene, a sprint normally follows the calendar month.

What does done mean?

A task is done when its requirements are met and unit testing has passed. A user story, Feature or Epic is done when everything beneath it is closed, tested and documented with release notes — ProsessPilotene sets the status to Resolved, the customer sets it to Done.

Roadmap

A one-page visual overview of all deliveries to a customer, with timelines, estimates and status. Maintained using actual data from DevOps.

Testing standard

Testing follows ISO/IEC 29119 with specification-based, structure-based and experience-based strategies. The goal is to automate testing for 80% of deliverables, so repeat testing runs automatically for each new version.

ETC and EAC

ETC is the remaining time; EAC is completed time plus remaining time. When EAC exceeds the estimated work, it signals a budget overrun — so everyone must always keep remaining time updated in DevOps, without exception.

Work Breakdown Structure (WBS)

Epic
project or main deliverable
Feature
major function
User story
requirements from the user's perspective
Task
the work actually carried out

How we assess risk

Remove the risk
Reduce the impact
Accept the risk
Transfer to a third party

How to set a project budget

Standard allowances on top of consultant hours

The budget consists of the Work Breakdown Structure (WBS) plus fixed allowances. These rates affect the price, and customers are always invited to discuss them.

Working meetings and administration
30 %
Testing
20 %
Documentation
5 %
UAT assistance
5 %
Production deployment
3 %
Risk allowance on the total
10 %

Example from the handbook

A delivery with 1,200 hours of consultant time has standard allowances added to bring it to approximately 1,944 hours. With a 10% risk allowance, the budget comes to around 2,138 hours.

WBS + standard allowances + risk = budget.

Documentation and templates

Standardised templates make every project familiar — from the work package that opens the project to the final report that closes it.

Portfolio management

Roadmap
Visual overview of all deliveries for a customer
Steering committee template
Agenda and reporting for steering committee meetings
Financial report
Status of hours, budget and forecast

Project management

Work package
The contract document defining the project (see the outline alongside)
Project plan
Timeline, sprints and milestones
High-level solution description
Architecture and deliverables in context
Test policy
Strategies and quality requirements for testing
Risk matrix
Probability, impact and actions
Project closure
Final report and evaluation

Project work

Kickoff presentation
PowerPoint template for project initiation
User story template
“As a … I want … so that …” with acceptance criteria
Training plan
Courses, target groups and delivery

The templates are ProsessPilotene's working tools and are shared with the customer by the project manager or account manager when needed.

Template

The work package — standard outline

Show outline · 11 sections

Background — what the problems are, where they occur and why
Customer with KAM and SL
Objectives
Customer with KAM and SL
Expected value creation
Customer with KAM and SL
Key deliverables with estimates
SL with the customer
Description of user experiences
SL with the customer
High-level timeline and baseline
PM with the customer
Budget
KAM with PM and the customer
Assumptions and interfaces
All parties
Administrative procedures and methodology
Standard text, approved by the customer
Tolerance limits and approval method
Standard text, approved by the customer
Signing at initiation and on approval of the delivery
KAM obtains the signature

User adoption and training

Success is measured by users actually adopting the solution, rather than by deployment to production. That is why the customer's management commits to the training strategy from the start.

Train-the-trainer
ProsessPilotene trains the customer's superusers, who then train their own colleagues. This scales well and builds internal ownership.
E-learning and blended learning
Documentation is converted into e-learning completed before the course day, freeing classroom time for practice rather than presentations. The handbook recommends this approach.
Classroom courses
Around 10 participants per course, in 45-minute sessions: introduction, theory, demonstration, practical exercises and review.
Self-study
Self-paced courses and guides, with follow-up and user support available afterwards.

The three-stage model for user adoption

Motivation
The customer ensures employees understand the solution's impact on them and on the business — before training begins.
Training
Delivered in the way that works best for the target group — blended learning, combining e-learning and classroom teaching, is recommended.
Follow-up
The most important part: practice with realistic work tasks, planned follow-up activities and accessible user support.

Ready to learn more?

Our learning pages bring together the courses, guides and materials that support the training strategy above — for customers and employees.

Explore our learning pages Browse our courses (in Norwegian)

Want to practise on your own? Browse the guides.

Project Handbook

How ProsessPilotene delivers projects. The methodology, roles, and checklists that ensure the right deliverables, on time and to the right standard, in every project.

This page summarises the project handbook for customers and employees. As a customer, it shows you what to expect from us — and what we will expect from you.

Project management office

The project management office (PMO) owns the delivery methodology and has overall responsibility for every project ProsessPilotene undertakes.

The project handbook is public and can be shared with customers — it belongs to ProsessPilotene, and this page presents its content in brief.

The purpose of the project management office

Strengthen project management as a discipline at ProsessPilotene
Establish consistent methods and ways of working across all deliveries
Ensure quality, progress and control in every project
Manage risk across the entire project portfolio
Coordinate reporting of key figures from all projects
Enable growth and larger projects

Delivery methodology

Four phases from enquiry to application management. The project process takes over where the sales process ends, and concludes where application management begins.

Sales
Process owner: Head of sales
The sales process establishes the basis for the project: a work package describing the project and, for larger deliveries, a high-level solution description and a roadmap. The aim is a shared foundation understood by both the customer and those responsible for delivery.
The phase is complete when
Signed work package and approved project plan. Responsibility transfers from the KAM to the project manager.
Key activities · 7
- Register and qualify the enquiry
  KAM
- Prepare the work package — background, objectives and value creation
  KAM
- Detailed list of deliverables with estimates
  Solution lead
- Advice on architecture, testing and training strategy
  Enterprise architect, test manager and training lead
- Project planning: WBS, RBS and schedule
  Project manager and solution lead
- Agree the plan and budget, sign the work package
  Customer and KAM
- Tentative resource bookings become confirmed bookings on approval
  KAM
Initiation
Process owner: Project manager
Initiation builds commitment among all project participants. This phase often takes four weeks — time well spent: the foundations laid here determine how efficiently the project will be delivered.
The phase is complete when
Everyone knows why the project exists, what will be delivered and what their role is. Approval by the project team or steering committee starts delivery.
Key activities · 7
- Allocate and mobilise resources with clear roles and scope
  KAM and project manager
- Review the work package, plan, strategies and estimates — catch mistakes early
  Entire project team
- Establish strategies for information architecture, integrations, testing, data migration and training
  The project manager leads the work
- Set up Azure DevOps: WBS, user stories, test plan and training tasks
  Project manager, solution lead, test manager
- Plan the first sprint in detail and prepare the kickoff
  Project manager
- Hold the kickoff — demonstrate the project's benefits for the customer
  Project manager and customer
- Establish the meeting schedule, administrative procedures and development environment
  Project manager and CRM consultant
Delivery
Process owner: Project manager
The delivery phase fulfils the work package. ProsessPilotene uses Prince2 Agile for agile projects and Prince2 for waterfall projects. All work is documented in Azure DevOps, and time is recorded using 7Pace.
The phase is complete when
A delivery that meets the requirements in DevOps. Status is tracked using traffic-light KPIs for progress, scope, time, resources, risk, finances and objectives.
Key activities · 6
- Plan: define and estimate tasks in DevOps
  Customer and solution lead
- Design: specifications, process descriptions and UX in the WIKI
  Customer and solution lead
- Develop the solution in line with the requirements in DevOps
  CRM consultants
- Test your own deliverables and carry out customer acceptance tests
  CRM consultants, test manager and customer
- Roll out: demonstrate, deploy to production and train users
  Entire team and customer
- Evaluate each sprint with a retrospective
  Project manager
Closure
Process owner: Project manager
Closure brings the project to a controlled end: deliverables are approved, lessons are collected, and ownership transfers to application management.
The phase is complete when
The steering committee formally closes the project, the application management team takes ownership, and the customer continues working with their KAM.
Key activities · 7
- Prepare the final report and financial status
  Project manager and solution lead
- Update the list of known defects, issues and risks
  Solution lead
- Revise the backlog with suggested improvements for the customer
  Solution lead and project manager
- Demonstrate the result to the steering committee
  CRM consultant
- Hold a retrospective with the project team and evaluate the project with the customer
  Project manager and KAM
- Formally close the project at a steering committee meeting
  Customer
- Hand over to application management and release resources
  Project manager and KAM