We take pride in delivering results through projects we do for customers like you.
Our teams work with customers in different industries, geographies, and sizes — ranging from 500 to over 100’000 employees.
We understand that every customer is different, and may come from various backgrounds and environments. The common factor is that our customers want to solve a problem within constraints like time and budget and with as little risk as possible.
This is why, after over 10 years of successfully delivering projects in over 20 countries, we have created our methodology of delivering projects predictably with little risk.
We have chosen to build our project delivery method based on Scrum. We acknowledge that your organization might not use Scrum or a similar approach. Don’t worry — we will adjust accordingly when we communicate with you. Internally, we will keep to our project delivery methodology. We know it works!
We deliver projects in four distinct phases — each with a clearly stated goal and outcome. These phases are:
What can you expect during each of these phases, and what is the outcome?
To deliver the right project outcome, we need to have a shared understanding of:
These are the goals of the Envision and Plan phase in our project delivery methodology. During this period, our consultants work with you to clearly define these four elements.
At this stage, we discover and document with you and your team the project goal and scope. Scope tells us all that is required to be delivered, what functions the solution needs to provide, and what problem it needs to tackle.
The project goal might not be directly related to system functions or a specific solution. It is the goal from the business perspective. It is why we’re starting the work, whereas the project scope tells us what both sides expect the outcome to be.
Why do we need to know WHY you’re doing this project? It might affect the way we deliver it. For example, the speed of delivery may be more important than feature-complete because the time to market is crucial to meet your goal.
The business goal of the project gives us our North Star for the delivery process.
The project scope is defined and documented in writing. Depending on the project type, this document can include architecture, wireframes or application design, and similar elements. The project scope also includes a clear definition of what it means when something is DONE!
It is crucial for us and for you to have a clear and shared understanding of what it means. We understand that things “almost finished” are not “done”, and value is only in things which are “done.”
Based on this document, our team creates a project backlog within our Azure DevOps instances. It defines the features and user stories for our team to deliver.
Project backlog is where the projects live on our side during project delivery. I will get back to it a bit later.
We have the first outcome of our project journey together:
Now it is time to move to the next phase.
This is the moment when the Project Owner has a clearly defined project scope and backlog, and assembled the project team on our side.
For delivery, we follow the Scrum methodology. We plan project sprints and work on project backlog to define them. Each sprint starts with Planning, after which our project team takes on the Implementation stage. At the end of each sprint, we go through its review and retrospective.
Predica project team will want you and your team to be included in this cycle and be active project participants at this stage. We know that the best results come from the project where you and your team are engaged in ongoing project delivery.
This brings the best value, allows us to validate the project results quickly, and correct the scope or assumptions without waiting for a lengthy development cycle to finish.
In the development cycle, we onboard the project into the full DevOps lifecycle and CI/CD process. Why? It lets us maintain the quality and speed of operation. When it comes to deployment, we know that we can repeat the process and quickly react if something goes wrong.
How long each sprint takes, what is the number of sprints, and when do we deploy the solution to production – this is all agreed between you and the Project Owner on Predica’s side.
At each sprint, we clearly state and communicate:
What you gain from this process:
The project completes with release into production! In shorter projects, we typically have one release after a few sprint cycles. For larger projects, we might agree on an interim release cycle.
It is time to put the project into the hands of the users. We test and verify the project deliverable across all cycles. Still, when we come to the release point, we go through User Acceptance Tests.
User Acceptance Tests at the release stage of the project have to confirm that the product delivers what the scope defined, and that it fulfills the agreed business goal.
If we identify defects (it will happen) or new requirements, we document everything in the project backlog. Project backlog is the single point of truth for all of us.
After tests, when we can confirm that the current increment is ready for production, we release it! In most cases, we do it through the CI/CD pipeline, so it is an automated process to minimize the risk.
There is an important activity at the end of release: project handover!
We are here for a long relationship, but ultimately it is your team who will operate the solution in production (unless you decide to work with us in a Managed Service model). We spend additional time to make sure that knowledge about the solution stays with your organization to the full extent.
At this stage, the project might end, and we will part our ways, or it might go in one of two directions:
Managed Service is an operational part of the project. Why did we include it in our project methodology?
We don’t believe that the project value is in the development process. The project is done and is a success when people can use its result. If this product is an infrastructure or application, it might require operations.
Our Managed Service team ensures that the business goals of the project will not be at risk because of operational issues. You can read more about how it works in practice in our Damco project case study.
That’s it. The four phases of the project. Repeat in a predictable way to deliver projects with low risk. We have our tooling around it to make sure that the project runs smoothly; it is on-track and delivers the planned outcome. It ensures that at each stage, we can answer your questions:
Got a business challenge you need help with? Contact us to discuss it!
Your company has decided to build a PaaS-based cloud solution and you’ve been tasked with architecting it. You went th...
Recently, I showed you my favorite extensions I use when working on projects in Azure DevOps. As I promised you, I’...