How WorkMesh Supports Projects
One of the biggest lessons I have taken from working on projects is that having information is not the same as managing it.
Most projects have plenty of information. They have risk registers, change registers, interface registers, safety systems, procurement trackers, contract registers, compliance records and reports. The problem is often what happens between those things: who needs to do something, when do they need to do it, has it actually been done and what happens if it is not?
That is one of the problems we wanted WorkMesh to solve.
Email is still doing too much project management
A surprising amount of project control still happens through email. Someone updates a spreadsheet and sends, "Hey George, I've done my update. Can you jump into the spreadsheet and take a look?"
George probably intends to do it, but he also has meetings all day, another 50 emails and a problem happening on site. The request gets lost, somebody follows it up later and eventually the project spends more time chasing the process than completing it.
WorkMesh changes that by turning the requirement into an Action. The record stays in the system, the Action stays with the responsible person and the project can see when it becomes overdue. If escalation is required, the system can do that as part of the process rather than relying on someone sending another email.
One project, many workstreams, one Action view
A project team does not work in one register. The same person might have something to do in Change Management, another Action in an Interface Register, a risk treatment, a procurement approval and a compliance activity due at the same time.
If every workstream manages its own to-do list separately, the individual has to keep checking all of them or reconstruct the list from emails and meeting notes. WorkMesh is designed to bring those responsibilities together so the workstreams can remain separate while the user still gets one clear view of what needs their attention.
That is where the shared Action engine becomes particularly valuable. The system becomes the custodian of the to-do list rather than relying on the individual to remember everything that has been sent to them.
Change and Interface Management
Change Management is one of the easiest examples. A change may require input from Commercial, Planning, Engineering, Project Management and the client, and the process only works properly when each person knows what they need to do and does it on time.
It breaks down when one approval disappears into an inbox. WorkMesh keeps the change record and the associated Actions together, giving the project a clearer view of where the change is actually sitting and making it easier to see when one part of the process is holding everything else up.
Interface Management has the same issue. Recording an interface does not resolve it. Someone still needs to provide information, review something, confirm a date or make a decision, and those activities need to be managed as Actions rather than simply being noted in a register.
Safety, Risk and Compliance
Safety, risk and compliance all rely on the same basic principle. A problem is identified and then somebody needs to do something about it.
A safety issue needs corrective action, a project risk needs treatments and a compliance requirement needs evidence. The project team should be able to see when those things are not being completed without having to manually review hundreds of records.
That is where exception-focused dashboards become useful. The Project Manager or Project Director can concentrate on the things that are late, escalating or outside the expected position rather than spending time looking through information that is already under control.
Contract and Procurement
Contract and procurement work also involves a lot of time-sensitive activity, including submissions, approvals, evaluations, notices, procurement decisions and commercial reviews. Many of those processes still rely heavily on email, which makes it easy for an important step to become buried in normal project correspondence.
WorkMesh gives those activities a clearer home. The contract or procurement record holds the information, the Action tells the responsible person what they need to do and the project can see whether it has actually happened.
The project team changes
Projects also move people around constantly. Someone leaves, somebody is replaced, a person moves onto another package or a new manager takes over halfway through the job.
Where responsibilities are assigned through a role, the work can remain with that role rather than being stranded with the person who previously held it. That can remove a lot of administration during project team changes and reduce the risk of responsibilities being forgotten simply because somebody moved on.
Reporting should use the information the project already has
Project teams spend a lot of time producing reports from information they have already entered somewhere else. If the project has spent the month managing changes, interfaces, risk, safety, compliance and Actions inside the system, the reporting process should use that information rather than asking people to collect it all again.
Scheduled snapshots and automated reporting can build the reporting cycle around the project calendar. The Project Manager still owns the message and the interpretation, but the system should do more of the repetitive work needed to assemble the report.
That means less time copying information and more time understanding what the information is actually telling the project.
Projects need flexible systems
Every project is different. A road project is not the same as a rail project, a small project is not the same as a multi-billion-dollar programme, and even two projects for the same client can have different contracts, stakeholders, governance and reporting requirements.
Project Managers also manage differently, so the idea that one rigid system should dictate the same process everywhere has never made much sense to us.
WorkMesh is intended to be configured around the project, including different fields, workflows, access, approvals and reporting requirements. The system should fit the way the project needs to operate.
Where the value shows up
The value of this type of system is sometimes easiest to understand after something has gone wrong. An unapproved change that should have been caught, a monthly report that did not go out, a critical Action that everybody assumed somebody else was dealing with, paper records that now need to be manually entered or a decision that sat in an inbox for days.
Most experienced project people can probably think of an example, and those problems can cost a lot of money.
WorkMesh is designed to make them less likely by giving the project clearer processes, clearer Actions and better visibility of what needs attention. That is the type of project control we want the system to support.