Co-designing a project management system.

Steps Community is a social enterprise in Bangkok that supports neurodivergent people through inclusive education, training and employment.

As Steps has grown, so has the number of projects running across its teams. Some are internal, such as people development and operations. Others are for clients and partners: training, consultancy, research and advocacy, sometimes all as stages of one project. They run from a few weeks to a year or more.

Projects were coordinated informally, through Slack and Google tools. That made it hard to manage them the same way from one team to the next.

Steps had tried project management tools before and found that a one-size-fits-all approach did not last. It needed more than a new tool: it needed processes, roles and team habits that fit its culture and could grow with it, introduced with flexibility and empathy.

Co-design and put in place a practical, sustainable project management framework that fits Steps’ values and mission.

The work was planned in three phases. Discovery would set the direction, scope and priorities. A pilot would test and refine the new processes and tools on real projects. A rollout would then take them to every team.

Discovery ran over four workshops with Steps’ management, business unit leads and operations staff.

The first explored why change was needed, the challenges and the opportunities. The second assessed how each team works today: a day in the life, the pain points, and a map of the current process from a new request to project closure. The third was a focus group and a readiness survey, answered by 22 people across the teams. The fourth played the findings back and set priorities together.

The findings were consistent. Processes differed from team to team. Teams had little visibility of each other’s workloads. Review and sign-off for deliverables, reports especially, were unclear. Coordination leaned heavily on meetings. The teams hoped for clearer, standard processes and better visibility. They feared low adoption, and losing Steps’ values in the change.

Discovery ended with fourteen priorities, from a RACI matrix (who is Responsible, Accountable, Consulted and Informed for each task) and approval flows to a task management tool, training and a decision log. The change followed ADKAR (awareness, desire, knowledge, ability, reinforcement), a model that gives the people adopting a change as much attention as the system itself.

The pilot ran from November 2025 to January 2026, on two types of project that between them involve every business unit: corporate projects and school projects. The first month set up the process: the RACI matrix, approval flows and a standard workflow, co-designed in workshops. The second set up the tool. ddx compared two that cover tasks, projects, time and resources, then configured the chosen one to match the agreed workflow, with templates for pre-sales and project tasks. The third month put both to work on live projects. Training ran alongside, on the job.

In January 2026 Steps’ leadership team agreed a social contract: an agreement, written by the team, on how its members work together.

By the end of the pilot, eight of the fourteen priorities were in place.

They were the RACI matrix, the approval flow, the work process, the social contract, task management, resource management, training and the decision log. Task and resource management run in the same tool, managed by different people.

The pilot left Steps with one documented workflow for a project, from a new enquiry and proposal through planning, delivery and closure to a client debrief. It runs on a set rhythm: task updates daily, progress and resource planning weekly, and a monthly review of strategy, capacity and the pipeline. The workflow is written up in a shared knowledge base, which the rollout proposal planned to extend.

Document structure, version control and change assessment moved into a proposal to roll the framework out to the business units outside the pilot.

The teams named the risks before the work started. In the readiness survey they worried that the change would be poorly explained, that nobody would own the new processes, that it would add to full workloads, that some teams would adopt it and others would not, and that it would fade once the project ended.

The pilot was built around those worries:

Explaining the change. The teams designed the RACI matrix, approval flows and workflow themselves in workshops, so they knew the change before anyone announced it.

Ownership. The RACI matrix sets out who does what at each step, and the decision log records who decided what.

Workload. Training happened on the job, on live projects, not in separate sessions on top of the day job.

Consistency. The pilot used corporate and school projects, which between them involve every business unit. That meant it tested the hand-offs between teams, not just one team’s work.

One place to work. The teams asked for a single platform. Tasks and resources are now managed in the same tool, with a clear owner for each.

Making it last. The leadership team agreed a social contract, the workflow runs on a fixed daily, weekly and monthly rhythm, and it is written up in a shared knowledge base.

Three months was not enough for everything. Six of the fourteen priorities were not yet in place by the end of the pilot. Some of them, including document structure, version control and change assessment, moved into the proposal to roll the framework out to the rest of Steps.

What we learned:

Ask people what worries them, then design for it. The survey answers effectively became the brief for the pilot.

Choose pilot projects that cross teams. Change usually breaks down at the hand-offs between teams, so that is where to test it.