How WorkMesh Supports Projects

How WorkMesh Supports Projects

Projects generate a huge amount of information. Risks, changes, interfaces, safety issues, contract actions, procurement decisions, compliance requirements, approvals and reports all need to be managed at the same time. In my experience, though, the biggest problem is normally not collecting that information. It is turning the information into clear Actions and making sure somebody actually does something with it.

That is one of the main problems I wanted WorkMesh to solve. I did not want to build another register that simply records what is happening on the project. I wanted a system that helps move the work forward by giving people clear Actions, clear ownership and clear processes, while also giving the project team better visibility of the things that are not happening when they should.

Projects are still managed through too much email

A surprising amount of project management still happens through email and spreadsheets. Most people who have worked on projects have seen some version of: "Hey George, I've done my update. Can you jump into the spreadsheet and take a look?"

George might fully intend to look at it, but he is in meetings, something comes up on site and another 20 emails arrive in the meantime. By the time he gets back to his inbox, the message has disappeared into the noise and two days later someone is asking whether the review has been done.

The spreadsheet might contain all the right information, but it is not really managing the process. There is no clear Action sitting in front of George telling him exactly what he needs to do, there may be no escalation if he misses it, and the audit history around who changed or reviewed something can be limited. Depending on how the spreadsheet is being managed, there can also be real problems with access, security and version control.

WorkMesh is designed to take that type of process and make it much clearer. Instead of relying on an email asking somebody to remember to do something, the system creates the Action, assigns the owner and keeps the work connected to the record it came from.

Let the system keep the to-do list

I do not think project teams should have to search through emails every morning trying to remember what they promised to do. The system should keep that record for them.

That is how I see the shared WorkMesh Action engine working on a project. You log in and you can see what is overdue, what is coming up and what requires your attention. You open the Action, see where it came from, understand what needs to happen and work through it.

In that sense, WorkMesh becomes the custodian of the project's to-do list. The more project processes that are connected, the more useful that becomes because the individual no longer needs to maintain a separate mental list for Change Management, Interface Management, risk, safety, contracts, procurement and compliance.

Those workstreams can remain different because they are different processes, but to the user they can still come together as one clear view of the work that needs their attention.

Change Management

Change Management is a good example because it normally involves several people and several decisions. Someone raises the change, Commercial may need to assess the cost, Planning may need to look at the programme impact, Engineering may need to provide information and the Project Manager may need to approve it. Depending on the project, there may also be a client approval required.

If that process is managed through email, it does not take much for one step to be missed. Someone is busy, an approval sits in an inbox and the project keeps moving while everybody assumes the process is still progressing.

With WorkMesh, each part of the process can create the right Action for the right person. The change record stays in the system, the Action tells the person what they need to do and, if they do not do it within the required timeframe, the Action can escalate.

That can be the difference between identifying an unapproved change early and discovering weeks later that work has progressed without the right approval.

Interface Management

Interface Management has the same basic issue. An interface register can tell you that two packages, contractors or disciplines need to coordinate, but recording the interface does not mean the coordination has happened.

Someone may need to provide information, review a drawing, confirm an access date or make a decision before another team can proceed. Those are all Actions, and they need owners and due dates rather than simply sitting as another row in a register.

By keeping the interface and the Actions together, WorkMesh can help the team move from identifying the interface to actually resolving it.

Safety, Risk and Compliance

The same principle applies to safety, project risk and compliance. A risk register is useful, but a risk treatment that nobody completes does not help the project. A safety inspection can identify an issue, but somebody still needs to fix it. A compliance requirement can be documented perfectly, but somebody needs to complete the required activity or provide the evidence.

This is where the Project Manager or Project Director needs a different view from the person completing the Action. They should not have to read every record in every register just to work out what is going wrong.

The dashboard should bring the exceptions forward. Which safety issues are still open? Which high risks have treatments that are overdue? Where has a compliance requirement been missed? Which Actions have escalated? That gives management a much more useful view of where attention is actually required.

Contract and Procurement

Contract and procurement processes also involve a lot of time-sensitive activity moving between different people. There are submissions, approvals, evaluations, procurement decisions, contractual notices and obligations, and many of those activities are still managed through a combination of email and spreadsheets.

A missed procurement approval can delay a package, while a contractual notice might have a deadline that has a real commercial consequence. If the process is important enough to matter to the project, I think it should have a clearer owner than an email sitting in somebody's inbox.

WorkMesh keeps the information with the contract or procurement record and uses Actions to make the responsibility visible. The project can see what needs to happen, who owns it and whether it has been completed.

Work on the go

Projects do not happen behind a desk. Project Managers, engineers, supervisors and other team members spend a lot of their time in the field, moving between meetings or dealing with problems away from their computers.

That is why the phone applications are important to how we are building WorkMesh. The goal is not simply to give people a smaller version of the desktop system. Where the workflow supports it, we want somebody to be able to review what they need, complete the Action, provide the required information or approve something and then get back to work.

If a decision can be made safely from the field, the project should not have to wait just because the person is two hours away from their computer.

Roles should carry the work

Project teams also change constantly. People leave, move onto another package or get replaced, and a new Project Manager, Safety Manager or Commercial Manager can arrive halfway through the project.

Where responsibilities are assigned through roles, WorkMesh can keep those responsibilities with the role rather than tying everything to the individual who happened to be in the position at the time. Change the person assigned to the role and the work can move with it.

That is much easier than trying to work out which spreadsheets, Actions and responsibilities belonged to the person who just left the project.

Reporting should come from the work

Reporting is another area where projects spend an enormous amount of time. The project team already does the work during the month by updating risks, managing changes, closing safety Actions, resolving interfaces and completing compliance activities. Then at the end of the month somebody often spends days collecting much of the same information again to build the report.

I think the system should do more of that work. If the information is already in WorkMesh, scheduled snapshots and automated reporting can use it to create controlled reporting outputs around the project's reporting calendar.

That does not remove the judgement of the Project Manager or the need to explain what the information means. It removes the repetitive work of rebuilding the same tables and reports every month, so the project team can spend more time understanding the information and deciding what to do about it.

Every project is different

Flexibility also matters because every project is unique. Different clients, contracts, stakeholders, communities, delivery models, approval requirements and reporting expectations all change the way the project needs to operate.

Project Managers also have their own way of organising and controlling the work. No two projects are alike, so I do not think it makes much sense to expect every project to fit into exactly the same rigid system.

WorkMesh is intended to be flexible like a project. The system should be configured around the way the project needs to work rather than forcing the project to change simply because the software has a fixed way of doing things.

The things that cost projects money are often simple

When projects get caught out, it is not always because of an incredibly complicated technical problem. Sometimes a change was never approved, a report did not go out on time, somebody missed an Action or an important decision sat in an inbox for three days while everyone assumed somebody else was dealing with it.

Sometimes the project also ends up with paper records from the field that somebody has to manually enter into a computer later. All of those things create cost, delay and unnecessary administration, and most people who have worked on enough projects can probably remember a situation where a better process would have saved a lot of time and money.

That is what I want WorkMesh to help projects with: less noise, clearer Actions, clearer ownership, better visibility and less manual reporting. The project team should spend more time doing the work and less time chasing the process.

Build better processes. Drive action. Reduce cost.