5 main challenges on a project with many contractors. And how to solve them

Recently I’d worked on an assignment where it felt like battling a fire in deadwood all the time. Contractors and subcontractors, numerous suppliers and clients who are the end-users but not exactly. You know what I mean now? When all communication, information and documentation pieces spread in opposite directions and the more you try to collect them all the more you understand how desperate that is.

After a nice portion of pity and compassion to yourself you realize that there is still work to do, put on your firefighting suit and get back to challenges. Love those!

I’d like to highlight 5 main challenges that I faced on that project and share with you the solutions I came up with together with my team.

1. Collaboration between all parties

• Contracts have to be reviewed and signed. Reviewed first! If you have a permanent or favorite subcontractor, discuss contract details (especially costs and schedule) with them first, before promising anything to the client. Would be wise to involve different team members in the review stage. One of our suppliers denied testing their deliveries because it wasn’t stated in the contract. On the next project QA Lead was involved in contract review.
• Requirements on such projects are several-sided: between client and us, between us and suppliers and subcontractors. All specifications should go through a requirement management process. Just keep in mind that all further work will be requirements dependent, so don’t try to save money on the business analyst role. We used Confluence for the storage of decomposed requirements and to track changes.
• Communication. All meetings’ haters can skip this part because I’m talking about the importance of meetings (weekly, biweekly or daily) on different project stages. It’s not given that the whole team has to be involved in meetings with all parties. But the meetings have to be held and meeting notes shared with the team. Personal connections shouldn’t be underestimated either. If it’s geographically possible, having onsite workshops together with client would strengthen relationships with the team and make further communication easier.

2. Keep track of issues

The whole project is about issues- they have to be planned, prioritized, addressed. Some of them are expected and some occur randomly together with a headache. We used Jira for issues tracking — tasks, sub-tasks and failures. We had several Jira projects:

• internal for managing day-to-day activities
• shared with client (it was important for certain reasons not to mix it with internal one)
• shared with the main contractor to track their progress

Jira allows you to create a board that would combine and display several projects which are very useful in internal daily meetings.

• Service desk Jira project for issues before release. The main reason for that was in many parties being involved (suppliers and subcontractors) who had to register failures, monitor them and report fixing without having access to the main Jira project (you don’t have to pay for customers in the service desk. But “customer” accounts have access to a help desk where they can report issues, observe created and change status. Also, Jira issue can be created based on e-mail sent to the address that you set up. The latter is especially helpful when you have people outside the office)
• Service desk for issues on production after release. For obvious reasons it shouldn’t mix with the previous one

Another place where we tracked the events was the project log. It was a long list of all the stuff happening. Had a phone conversation with a client? — Add a registry to the log. A supplier reports on a big delay? — Add a registry to the log. Requirements were changed in the middle of the project? — You got it.

We brought this practice from a previous similar project where we implemented a log too late. But this time it helped us not to lose any events in different collaboration chains and easily get back to it later.

3. Technical documentation. Storage and update

I never stop saying that all project documentation should be kept in ONE place, well organized and always up to date. I like to use one family of products so my obvious choice was Confluence with internal space and the one shared with the client. Today’s Confluence offers many sweet templates and macros to make pages both useful and easy to read. It also has smooth integration with Jira and other external products. One small thing. There is always someone in organisation (often in top management) who is a huge fan of SharePoint or Excel files on their local machines. Don’t ask why. If you’re not lucky enough to bring them on your dark side, all you can do is to mention that doc on a Confluence page and leave a link there. The local-machine-case is clinical and we just have to fight that (are you still having your firefighting suit on?)

4. Expectations management.

Schedule, budget, quality, risks, responsibility distribution — these have to be evaluated, discussed, reviewed and reflected in the contract. Just remember, there is always someone who pays for fuck-ups and better to discuss it on the shore.

5. Merging several contractors and suppliers on the delivery stage

Sometime before delivery the fire suddenly becomes hotter and time works against us. If your collaboration with contractors, subcontractors and suppliers is still chaotic then it’s too late and the firefighting suit won’t help. All of them also have issues with schedules, costs and quality. The issues and activities are tracked in Jira, documentation is kept in Confluence and responsibilities are described in contracts. That gives a feeling of control and helps to reduce anxiety. But there is always something else that wasn’t registered, was forgotten to update or just occurred out of the blue.

Here you’ve got to step in personally and talk to people often (I wrote more about rising responsibility within the team while talking to them in stressful situations here)Very important to keep an eye on team members so that no one burns out because of overtime or things going out of control. Smart task distribution and regular reporting will be super helpful.

There are many things that seem challenging on any project with numerous parties involved. I definitely recommend collecting best practices to use them on further projects and to share with other firefighters.

You’re very welcome to use mine and I’m looking forward to inspiring discussions.

I hope you all stay warm and never get burns. Or at least not painful ones.