Content:

1/ Dare to ask if you don’t understand something clearly. Don’t assume. 

Case: the client gave us a requirement, we did not clarify our assumptions and thought we understood everything. 

we think it this way ->  "we did the task" but it is not what the client wanted so no value was achieved in the end. 

It is a very common situation, young professionals sometimes have the tendency to avoid asking direct questions, shy and hesitate to raise questions. 

We think the clients may have a bad impression on us and may think we are not good enough. ... But it is actually the other way. 

We need to understand a thing clearly in order to have the right solution for it.

2/ Keep track and Document things that are changing

Things keep changing during projects for example - requirements, … Often we need the proof and evidence to show to our customers when they need it. 

Often we discuss/talk but if after the meeting, we don't have a summary note, or a follow-up email (or something that we wrap up what we discussed and agree on, things will be difficult if later you and your clients change opinions or forget what have been agreed on.

3/ Always start with an end in mind. Ex: what are the expected results and how will it benefit the user, if you are the user, how would you want the product to help you. (Persona)

4/ Have the courage to say no when it is required

"What is your responsibility in the overall project scope?". 

Be specific and clear of the scope and responsibility that you take. It will save you from being put in a situation where you feel disadvantaged 

Case: In our project, we worked hard and finished the tasks assigned before the expected deadline. The client may see that you have a bit of extra time and may want you to do significantly extra work "out of the scope" of the project. 

Be proactive in that situation and validate whether this is accepted as part of your current agreement and if the extra work is something you are equipped to work on. Clarify the situation with your manager and take also his view. Of course, if it is something small and you are happy to help the client, Then you should do it.

5/ Think the big picture. (Solution)

If you cannot have an expert to make the solution plan and architecture for the team, it may be risky.. Things should be much easier and organized when your plan and solution approach is clearly stated & agreed upon before starting the build. 

Case: During the first phase of the project, when we get to know the client's business process, what and how they do their business, their challenges, and requirements. Then relate to your solutions, 

What would you do to help them solve their issue and meet their requirement? 

But what happens if, during this build process, you identified a competency issue for e.g. you don't have a person that can do a specific (technical) task because of missing knowledge. 

If your evaluation of the client's need and your matching solutions are not optimized in advance, it will easily lead to a problem and or delay during the build.

6/ Assign the right task to the right person. 

Everyone in the team has their own strength and weaknesses as well as working habit. Observe, understand and delegate. 

Case: in my team, there are some members that are good at speaking and presenting, some are good at coding, configuring; some are good at documenting, writing. so, it is important to understand your team members and put them at the right position, to delegate the right tasks.