The Colart Way to Manage Projects

The official methodology for Colart

Who is this for?

This methodology can be used by anyone at Colart. This is a flexible methodology that can be used for multiple types of projects, covering a range of timeline lengths and complexities. Find out more about what distinguishes projects from BAU (business-as-usual) on the general page for Project Management at Colart.

The Development Team at Colart have created this methodology using industry standard agile processes and adapting them for Colart. We have excluded some aspects, and tweaked others to make sense for our context and business requirements.

 

Why is this important?

  1. Strategic goals alignment
    1. Quality: Striving for excellence in everything we do beyond delivering outstanding products and service, but also always doing our best to deliver on our promises to all stakeholders
    2. Agility: Achieve shared goals by being responsive, adaptable, and prepared to take calculated risks to find new solutions within a framework of simple & effective processes underpinned by collaboration
  2. Ease of understanding across departments and project roles
    1. If expectations are clear and standardised we can focus on delivering the best solution possible for the business
    2. If project roles are standardised and understood across the business then fulfilling those roles becomes less challenging, and projects progress more efficiently
  3. Standardised communications with senior stakeholders
    1. If the PM can exhibit control of the project it inspires trust in their skills
    2. If the path to escalate issues is clear then finding solutions is quicker
    3. If the status update is relevant and presented in a uniform way the stakeholders don't need to learn how to interpret vital information
  4. Clear accountability
    1. If the project delivery squad knows what they're empowered to do and accountable for then they can embrace a flexible approach within agreed restrictions
    2. If the stakeholders understand the responsibilities of their roles then decision making becomes simpler and quicker, and the right people are assigned to the Steering Group meetings and they can be held accountable
    3. Risks, tasks, and responsibilities can be allocated to different individuals in transparent communication, ensuring the right skill-sets are responsible for those outcomes.
  5. Anyone can take on a PM role.
    1. If the methodology is general and universal then it can be used by anyone who wants to lead a project (even if they aren't Project Managers by training).
    2. If we want to embrace agility then we need to work with Agile principles.

Workflow for project approval

New Projects

There is a dedicated workflow to submit projects for approval. This approval process goes to the Product Owner (PO) for the approval of the Product Owner or Sponsor of the project (depending on which is relevant).

We have divided projects into two categories to help ensure the level of documentation is relevant to the project size. The two categories of project:

  1. 6 months or less to deliver.
  2. More then 6 months to deliver.

The longer the project takes, the more detail is expected at the scoping/planning phase, and this is facilitated by the workflow form.

 

View a list of all projects on the workflows website.

More detail on the workflow

PMs use the form in Colart Workflows to submit project plans for the Product Owner or Sponsors approval. This is done before work starts, so that the project delivery squad is not at risk of delivering the wrong solution.

 

There is a flowchart diagram to illustrate the Workflow form cycle, click on the image to enlarge it:

We've also created a manual that explains the process in a different way.

Roles, RACI, and how projects are scoped

How to manage a project

To get started, introduce yourself and your project delivery squad (DS) to the roles and responsibilities of the Project Manager (PM) and Product Owner (PO). This slide deck explains the differences between these roles and how they work together to guide the DS and the project.

This manual also covers requirements and user stories, prioritisation, and RACI matrix for all roles in a project.

The Product Owner (PO)

A guide for all POs to use

Delve into the role of Product Owner in more detail.

 

POs define a vision for a product and ensure that that vision is aligned with Company ambitions. In some companies, the PO is a dedicated role. Our POs already have a role in the business, which means that the person has both a deeper and more holistic views of the product within the business, and has the ability to make quick decisions. The PM and PO work closely together and theis relationship is vital to all projects.

The Delivery Squad (DS)

What tools can I use to do manage my tasks?

Estimations are difficult to do an dthere are many techniques that can be utilised. 

We have created our own framework, base don industry standards and simplified for ease of adoption. These can be used for all project tasks.

Templates

Monday.com and Miro templates

These templates were created by the Development Team and have been used to successfully deliver projects to the business for a year prior to sharing here. The templates can be modified slightly to cater for your own project needs but ideally should remain as close to the ideal as possible to avoid possible missteps in managing the project

 

Miro

You can request access to Miro via Service Desk.

  • Requirements workshop (used to document, size, and prioritise all high- and low-level requirements durign Feasibility and Foundations)
  • Solution Approach Definition (This can take many forms, and is dependent on the architect tfor the project)

 

Monday.com

You can request access to monday.com via the Colart Workflows website.

  • Delivery Plan (used to control and measure the delivery rate of the solution)
  • Budget (used to track predicted and actual costs)
  • RACI Matrix (designates and makes transparent what is expected from the team)
  • Risk Assessment (used from feasilibility until the project is delivered/launched)
  • Management Approach Definition (used to define howthe project team will work together, how decisions will be made, how risks will be managed, how progress will be tracked and reported, and how quality will be ensured)
  • Development Approach Definition (the Solution Architect will use their own template)
  • Project Approach Questionnaire (used to ensure all project roles are clear in their role and how the project will be managed)
  • Project tasks - Sprints (used to hold all the tasks the Delivery Squad (DS) need to perform over the course of the project. Do not be tempted to split the tasks over several boards, as you will find it more difficult to analyse your delivery rate and other stats)
  • Project tasks - Simple (used to hold all the tasks the Delivery Squad (DS) need to perform over the course of the project. Do not be tempted to split the tasks over several boards, as you will find it more difficult to analyse your delivery rate and other stats)
  • Go/No Go checklist (specific tasks to be completed in order to launch, contributed to by the entire DS)
  • Project retrospective

 

Powerpoint

  • Steering Group Template (used to ensure steering group members accross the business receive information in a standardised format)

FAQs

Answering your questions

How detailed does the workflow need to be?

Each 'phase' of the scoping process needs to be 'enough' detail in order for it to proceed. This is defined by the PM and PO, in collaboration with the DS. So, for example, if the DS feel there is not enough information to create tasks for the first increment of work (maybe priorities aren't clear) then that needs to be addressed before the form is submitted. If the PO disagrees with the information in the form, the PM must amend it. And if the PM feels the PO has made all the requirements 'Must Have' then they can address this with the PO before any work proceeds.

 

Why is deadline not pre-determined?

Sometimes we have deadlines that are unavoidable, like annual events or contracts that have termination dates. In these cases, the scope of the project has to be (1) reasonable, and (2) prioritised so that the deadline can be met (if necessary by first descoping requirements that are 'Could Haves' and then descoping 'Should Haves'). In other projects, we need to give the DS the ability to estimate the entire project as a whole, without being pulled into too much detail. This means that they might be wrong about the complexity of some tasks at the point before they start working on them. As they know more, so the project end date becomes clearer. That is what the cone of Uncertaincy is, the more detail you know, means you can get a more accurate estimate.

 

What are the rules for MoSCoW prioritisation?

 

 

Why can't all my requirements be Must Have?

 

 

Who is supposed to size the requirements?