As you well know, the IT outsourcing industry is a highly competitive field. From large SI companies that have already built their legacies to mid-sized SIs boasting solid portfolios and traditions, and then to small SIs and freelancers armed with speed and agility, many diverse people are participating in the competition. Among them is here, an eager Assistant Kim who has taken on his first client project. Assistant Kim wanted to ensure the success of his first outsourcing project, and during conversations with the client, he spoke with a bright smile, saying:

• "Yes, of course! Absolutely possible!"

• "Wow, that’s a great idea! I’ll make it happen!"

• "Yes, understood! Just trust us!"

The client seemed to be very pleased with Assistant Kim. With such a friendly person accommodating all requests in front of them, they might have thought, it would be very comfortable to work together. Assistant Kim also felt proud, thinking, "Fortunately, we can start the meeting smoothly!"

However, as the project began in earnest, this seemingly perfect partnership gradually began to head towards tragedy.

• (Monday morning, KakaoTalk) "Assistant Kim, I thought about it over the weekend, and I think the main screen design looks a bit old. I’ll send a reference image, so please completely change it to this kind of feeling."

• (Tuesday afternoon, Email) "This is the staff member. The CEO looked at it yesterday and thinks it would be better to move the logo position back to the right. Please check."

• (Wednesday evening, Phone) "Ah, Assistant Kim. While we're at it, could you also add our company introduction video that I’m sending now to the login page? It seems simple..."

Assistant Kim's day was a frenzy, dealing with requests flooding in from various channels. Modifications based on the staff's input would be overturned by the CEO's appearance, and the so-called simple requests shook the entire development team. Ultimately, Assistant Kim found himself sandwiched between the client and the development team, working overtime every day, as the project began to lose its initial direction and go off track.

"I understand why the development team is struggling since we’ve accommodated everything the client wants. But why can't the client be satisfied?"

Does this story sound familiar to you? It’s okay. Many junior planners fall into the trap of being the 'nice planner' and often shed similar tears. Today, I would like to talk about a professional system that breaks this vicious cycle and truly earns clients' trust.

1. Time to Set the Rules of the Project: Kick-off Meeting

The tragedy of many projects often starts with the first button being fastened incorrectly. Many junior planners tend to think of the project kick-off meeting merely as a time to greet and meet each other. However, the true purpose of the kick-off meeting is to create the most important rules for our ship that will sail together for the next few months.

"We are professionals who want to make this project a success, and for that, we need clear agreements between us."

We typically speak like this at the kick-off meeting and ensure we agree on the three main rules. Allow me to introduce these clauses.

Article 1 (Identifying Decision-Makers): "Who will provide the final confirmation?"

The first thing to do is to clearly define who will make the final decision. While various people such as staff members, team leaders, and the CEO can express their opinions, if we don’t know whose word to follow when those opinions clash, the project will drift.

"If we have multiple channels for feedback, it may create issues. For instance, if the staff and the CEO have different opinions, if we pre-establish whose opinion we should ultimately follow, we can avoid confusion and move faster. Who should we designate as the final decision-maker for this project?"

By politely yet clearly asking, you can later avoid accusations of, "Why did you proceed like this based on A’s opinion? The CEO thinks differently."

Article 2 (Establishing Communication Rules): "How shall we communicate?"

The second step is to establish rules for communication. We need to clarify the channels, frequency, and deadlines.

• Communication Channel: "To prevent omissions in all requests, please leave them in the Slack (or designated tool) channel. We might miss requests made via KakaoTalk or verbally."

• Feedback Deadline: "If you give feedback on the design draft by this Wednesday, we can deliver the revisions by Friday. Please understand in advance that if feedback is delayed, the overall project schedule may also be delayed."

While this may feel a bit stiff, these rules ultimately save each other's time and provide the most reliable safeguard against the project stretching longer than necessary.

Article 3 (Establishing Regular Meetings): "Let's meet every Wednesday at 2 PM."

Finally, promise to meet regularly. Rather than only meeting irregularly whenever issues arise, we should share progress and issues every week at a designated time. This way, we can prevent small problems from building up and exploding later as big bombs.

2. How to Win the War Against Ambiguity: Communicate Through Documentation

Now we have set the basic rules of the project. The next step is to document everything to eliminate any ambiguity. This is the process of translating vague ideas in the client’s mind into specific documents.

I think of a project proposal as both a 'product manual for the client' and a 'blueprint for our team'. To fulfill these two roles properly, especially the functional specifications must be written in meticulous detail.

Let's say we are planning a login feature?

[Before] Example of a Bad Proposal:

• Add social login functionality.

[After] Example of a Good Proposal that Saves You and Your Team:

• Feature Name: Social Login (Kakao, Naver)

• Basic Policy:

  • Users can sign up as new members and log in using their Kakao or Naver accounts.

  • During the first social login, they go through a consent procedure for the Terms of Service and Privacy Policy.

• Exception Handling 1 (Duplicate Account Case):

  • If a member tries to log in with a social account associated with an already registered email address, display a pop-up message saying, "This email is already registered. Would you like to link with your existing account?"

• Exception Handling 2 (API Error Case):

  • If the social login API call fails, display a toast message saying, "A temporary error has occurred. Please try again later."

• UI/UX Policy:

  • The button design follows the Primary Button-L type from the system design guidelines.

  • The text on the buttons will be "Start with Kakao" and "Start with Naver" respectively.

How does that sound? Can you feel the difference? Such detailed specifications wield incredible power:

• (To the Client) Clearly show them that the feature they are paying for is designed with great attention to detail, preventing the later statement, "This is different from what I imagined!"

• (To Designers/Developers) Greatly reduce the time spent asking the planner, "What do we do in this case?" and prevent the costs associated with rework from creating something incorrectly and having to fix it.

• (For the Planner Themselves) It becomes a clear basis for all work, serving as a powerful weapon to protect oneself from the client’s whims or confusion within the team.

Conclusion: A ‘Good Partner’ is Not Just a ‘Nice Person’

Successfully working with clients does not mean saying "Yes" to everything they say. Rather, it is about establishing clear rules together at the beginning of the project and communicating with the transparent language of documentation during the process to lead the project in the right direction.

This process may initially seem like a nuisance to the client. However, in the end, it reduces many risks associated with the project and increases the likelihood of success, which is a hallmark of professional handling, and this is undeniably the most certain way to give true trust to the client.

Instead of being a nice person, I suggest three actionable items you can start practicing right now to transform into a strong partner that people want to work with.

1. Create a 'Kick-off Meeting Checklist Unique to Our Team': Organize the three clauses introduced today, along with other essential agreements that must be reached with the client before starting the project, and start using it in the next project.

2. Practice Writing Detailed Specifications Starting with the Simplest Features: It doesn't matter if it’s a tiny function in your current project. Practice writing meticulously about exposure conditions, close button policies, anti-abuse policies, and exception cases.

3. Always Share Meeting Minutes Within 24 Hours: After meetings with the client, organize the decisions made and the upcoming action items, and be sure to share them within 24 hours, developing the habit of confirming, “Is my understanding correct?” An email can save you later.