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 30 years of successfully delivering projects in multiple 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 organisation 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!
What is the SoftwareOne project delivery method?
We deliver projects in four distinct phases — each with a clearly stated goal and outcome. These phases are:
- Envision and Plan
- Build and Stabilise
- Release
- Managed Service
What can you expect during each of these phases, and what is the outcome?
Envision and Plan
To deliver the right project outcome, we need to have a shared understanding of:
- Project goal from the business perspective
- Success criteria and how we will measure them
- Work which needs to be delivered
- Definition of done for work produced within the project.
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.
Project goal vs project scope
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, the 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. We will get back to it a bit later.We have the first outcome of our project journey together:
- Definition of business goal
- Project scope and a backlog build on based on this scope
- Work and schedule estimation.
Now it is time to move to the next phase.
Build and Stabilise
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.SoftwareOne 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. Project statistics for ongoing reporting[/caption]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 do sprints work?
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 our side. At each sprint, we clearly state and communicate:
- Product of the sprint and increment for the entire project
- Features that the current sprint delivers
- Issues and risks at hand.
What you gain from this process:
- Clear visibility into project progress
- Timeline for delivery of each project feature
- Single point of truth for all project issues and backlog items
- Visibility into project KPIs and status like build quality, test results, the number of backlog items defined and delivered.
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.
Release
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 minimise 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 organisation 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:
- Start the next iteration of the project, and the whole cycle will start again from project envisioning and planning
- The current delivered project phase will transition into Managed Service for us to help you get the most out of the running solution with minimal risk.
Managed Service
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.
Successful delivery is what we do!
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:
- How is the project progressing?
- What will be its deliverables in the next release?
- How is the progress doing vis-à-vis the project budget?
- What does it mean to complete the project and when will it happen?
Got a business challenge you need help with? Contact us to discuss it!
Author
