Chagwa is a Project Management Methodology. It targets the integration of best practices in project management in a concise framework.
Chagwa integrates three common project management methodologies
- Change control driven projects
- Agile driven projects
- Waterfall driven projects
Chagwa moves away from this way of thinking. Independent how your Organization is structured, the changes performed to the Product dictate the project methodology.
You therefore first need to analyze what changes are required to create or change a Product in your project. Only then you should make decision how to make these changes.
THE PROJECT MANAGEMENT OCTAGON
To understand how this is done, let's first consider the famous Project Management triangle. The concept is that any project tries to balance three core items in a project: what is being done (scope), in what time the project needs to deliver (time), and what the spending will be to reach the scope and timing (cost).
In reality there are five major project influencers that will also determine your project.
- Customer / Project Sponsor: can change organization or demands
- Stakeholders: positive and negative influencers for the project
- Quality: requires time and budget
- Risks: internal and external
- Resources: what / who is available?
The following applies for Change Control managed projects
- The Operations organization is responsible for the deliverables. A project lead follows up on proper implementation only.
- Costs are known: standard Operational Teams work. The key is that all changes are standard Change Requests.
- Scope is known: series of tasks executed as a change.
- The timing is vague: the project lead “baby sits” changes. The timing depends on availability of Operations or DevOps Teams.
- Governance on the project is done through Change Request reviews.
- The Project Team (Scrum Team) is responsible for the deliverables.
- Timing is known: Product Increment every 2..4 weeks.
- Costs are under control: Agile times have a fixed project team size, and spending is done per sprint.
- The scope is vague: the Product Owner can change User Stories, or stop the project anytime.
- Governance on the project is done through direct involvement of the Product Owner in the project.
- The Project Manager is responsible for the deliverables.
- The scope is known: the customer provides detailed requirements.
- The timing is determined: the customer defines milestones.
- The cost is vague: calculated after analysis and design.
- Governance is done through Stage Gate Reviews.
As explained higher, Chagwa proposes to decide on the project approach based on the changes to be done to the Product. It's not your Project Management Organisation that dictates the methodology to use, it's the Product.
Based on the previous analysis, Chagwa puts forward the following rules of thumb.
- The Chagwa Waterfall track should be used for projects where the cost of changing requirements or design in a project is unacceptably high.
- Choose the change control track if the work to be done doesn’t justify the effort for setting up a project, and when you accept that no clear end date can be given for the work to complete.
- Choose the Agile track if high interaction with end users is needed during development, and when the work can be done by a small and responsible team. Tasks to be completed must comply with the INVEST principle.
- Products following an Agile track must have a Product Owner assigned. The Product Owner must be given the time to assist the Agile Teams.
- Agile remains Agile, and Waterfall remains Waterfall, even in mixed projects. An organisation must be aware that successful Agile teams are managed differently from Waterfall driven teams.
- In mixed projects the planning is first done for the individual Products or sub-components. In a second step dependencies are identified. The third step integrates the planning based on dependencies. In a fourth and last step time contingency is built in for integrating Product Increments into the overall planning.
- Keep documentation to the minimum. Keep the Distrans level of an Artefact as low as possible. If an artefact with high Distrans cannot be avoided, keep the artefact simple and low cost.
The Chagwa process flow is then as follows.
OTHER CHAGWA CONCEPTS
The above is only a brief introduction to the Chagwa Project Management Methodology. Chagwa also includes the following.
- Chagwa comes with ready-to-use processes that can be used out-of-the box. If you already have Agile or waterfall driven flows in place in your organization, there's no strict need to replace these. Instead you can integrate them in Chagwa.
- Chagwa also proposes artefacts for documenting the Product and how a Product can be enhanced by means of incremental changes. The Business defines which artefacts are essential for Product and project documentation in the organisation.
- Chagwa allows multiple ways of executing a project. This means that integration of the project deliverables can become complex. Chagwa proposes the use of an Integration layer where multiple project deliverables are integrated through Change Control.