In this article, I would like to share my experience in daily project communication. I learned the tips I want to give during the last years and made, together with my fellow colleagues, good experiences with these. As a project leader, you need to find a balance between passing the clients’ requirements to the development team and coordinating all project issues. To be honest, this isn’t always easy. The following tips shall help to improve project communication:
1. Make Workshops and create Concepts
Clients have requirements you have to understand first. The challenge is to reach a common level of knowledge and a common understanding of a requirement. Mostly the project participants made different experiences and have different views, a different technical understanding and use terms in different kinds of ways. This is a risk right at a project’s start and might lead to hampered project conditions. That’s why you should, depending on the possibility and the scope of the project, invite to a workshop at the beginning of a project. After the workshop and on the basis of a protocol you can create a technical concept. The benefits are quite obvious:
- get to know the client personally
- understand the client’s wishes and targets
- get an overview of the project
- fix the project’s framework
- create a road map
- create serious offers
Finding a common wording a substantial task at each and every project start and remains a challenge for people getting into the project at a later time. Nevertheless, it is the basis for mutual understanding.
2. Create clear offers and offer positions
Behind a project request supposed to be clear there’s often a black box. A request like those sounds often like “Responsive Relaunch of our current website domain.com. Create an offer, please!”. Behind wordings like these, there are many open questions for agencies that need to be answered in order to create a serious offer. That’s quite different sometimes and requires a detailed workshop (see tip 1).
Let’s suppose we did the workshop with the client, the client fixed all needed details in the requirement specification sheet and made milestone packages out of it. The technical concept, the so-called functional specification sheet, is created. On the basis of these, we can offer a serious, concrete and detailed offer. In a separate meeting with the customer, we take a close look at the offer and I explain all details and terms and answer questions. This must be a meeting at the customer’s office as we at Inpsyde specialized on decentralized working.
On the basis of the clear offer positions and explicit wording, it’s easier for all project participants to understand the requirements and really achieve the project targets. Moreover, all tasks become transparent, comprehensible and measurable. In the end, the whole project becomes more tangible, more realistic and minimizes the project risk.
In software development, the most fatal and most expensive mistakes are made at the project’s beginning by requirements remaining unclear or underlying a different understanding.
3. Don’t create a fix Date as Deadline
Honestly: How often did you put a project online at a fixed date? In other words: Having fixed deadlines increases the probability to fail. Of course, a deadline is really important. Nevertheless, it is important to have a realistic one that doesn’t create pressure.
Very often project requirements and its date going online are terminated to a fixed date. So, one day is taken as a “deadline”. But too often this date is going to be shifted – due to several reasons:
- new requirements during the project
- delayed decisions
- Resource bottlenecks
- and many more reasons
In short: projects may have a delay. At least you should consider this in your plan and make a time frame for your GoLive. For example, you could have a calendar week instead of a fixed date. Except for the deadline, there are tasks being much more important in your project plan and implementation than adhering to a target gate. Of course, I don’t talk about projects which need to be online for certain reasons, for example fair dates, an Advent Calendar or something similar. But nevertheless, you should plan with a realistic implementation timeframe so that you won’t get under pressure.
Planing with a test phase with iterations for bugfixes creates a time buffer as well.
4. Create written result logs
“Those who write, remain.” This phrase says everything about this tip. After each phone call, I write down in keywords about which topics my phone partner and I talked about. This does not only create liability but also transparency and protection. Due to this short documentation, you can reproduce what you talked about and what kind of tasks result from that.
Particularly as most problems have their roots in communication. I made really good experiences with these short and smart logbooks (greets to Captain Kirk) and my customers attested that, too. Logs make daily life in projects really much easier. Of course, it’s more work. However, you save a lot of time at the end of each project due to your written notes. The way you do it isn’t important at first instance, just write down — take a paper if you like. Nevertheless, there are cool tools which I want to introduce in the next tip.
5. Implement helpful tools
Here some tools which make my work much easier:
Slack: Slack nearly replaced our E-Mail. It allows central project communication with clients and team members. I don’t want to miss this tool anymore. I put jour fixe logs as a note into it so that everyone has access to it. Moreover, there are thousands of integrations to other tools. However, you should stick to a netiquette and you shouldn’t forget that a chat doesn’t replace direct meetings or video conferences.
Evernote: the helpful digital notepad. I can recommend it to anyone who doesn’t want to write on an analog notepad first. Although I replaced it with the note function in Slack at the moment, the digital notepad can be really helpful.
Wunderlist: nice and easy To-Do list. Due to this, I stay focused – and there is nothing better than finishing tasks and making hooks.
Hubspot: a CRM in which we file correspondences with customers centrally. And it’s for free.
zoom.io: good video conferences with a whiteboard, screen sharing (for mobile devices, too) and conference rooms for recurring jour fixes. I don’t want to miss it anymore.
If you use some alternatives and other tools I would be pleased if you left your ideas as a comment.
6. Arrange collective Workflows
Knowing the way it goes. In order to create an understanding of the way we work among all project participants, it is useful to explain the processes to all being in contact with the project. Useful are flow charts or working with certain standards and approaches. As an alternative, you can also create individual procedures with your client.
That’s why we use Jira ticket templates with the minimum required information for each ticket. So we create information by always following the same scheme. Which details we need to have for a requirement or an error description is prescribed. In the following I will give an example with the appropriate markup:
// Short problem or requirement description
What’s happening currently?
// Describe the current outcome. Also add screenshots or mockups
What do I require instead?
//What is the desired result?
Steps to reproduce
// Describe each single step to make the problem/requirement comprehensable
* *Logged in/Not logged in:*
Moreover it’s useful to illustrate workflows so that they are clear, too. With lucidchart you can, for example, create flow charts quite easily.
7. Make regular Jour Fixes
Sounds easy — and it is. I have a fixed recurring date with my customers. It helps both sites to coordinate and give and get impulses. As the daily working life is sometimes busy, topics might be left undone. Thanks to the Jour Fixes, you never forget them. And although there sometimes might be no important topics, you should always have your Jour Fixes to stay in touch.
8. Make a Retrospective after projects
Reflection is a topic I really like. Especially talking with the client can extremely widen your horizon and strengthen the customer relationship. And of course, it’s also quite useful to take a look at the project implementation in your team.
A retrospective is about learning from all project participants and fulfilling tasks better in the future. Five questions help:
- Start doing: What should we start with?
- Keep doing: What should we keep because it worked out well?
- Stop doing: What should we stop doing?
- More: What should we more focus on?
- Less: What should we less focus on?
After answering these questions you cluster all answers in regards to their topics and create “Dos and Dont’s” for future projects. In the best case, you have a neutral moderator accompanying this meeting.
The given hints are some best practices that I as project leader value a lot. They might not be the solution for any case. Nevertheless, I hope I could give some tips for better project communication.
All in all, I want to say that open, transparent and honest project communication is key to a successful project. As is respectful contact with each other. As often: Talking with each other helps.
What are your experiences? Do you have further tips? Or another opinion? I’d be pleased to discuss with you in the comments below.