Project Manager and the Client

I found the first article below when scrolling through the Project Management Interest Group on LinkedIn. Check it out: (

“Becoming the Master of Client ‘Touch’” sparked my interest as I deal with clients on a daily basis. The word “touch” represents contact with a client that let’s them know you are thinking about them as well as things that may be significant to them. The article provides examples of client “touches” such as hand-delivering a proposal, sending industry specific articles to clients, and sending tools or check lists that make their lives easier.

In summary, the article highlights how the project manager has a responsibility to reach out to clients in quick, meaningful way that ultimately make the client feel comfortable with you. I see clients work with those they truly feel comfortable working with time and time again in my line of work. It is important to keep in mind all of the great skills we learn getting our MBA, but it is also very much about relationships we form.

The second article, “Managing Projects, Helping People,” suggests numerous ways that a project manager can walk the fine line of managing a project and a client relationship. Two aspects from the article I have found successful in client relationships are being honest and being an educator.

Being honest includes discussing how something may be a challenge for your team. By being honest, the client may be able to bring a perspective to the particular challenge you had not thought of previously. You can also include the client in the decision-making process to help build harmony on ideas. I have found explaining concepts, financials or outcomes in an honest light (i.e. why we are losing money on a particular portion of their business) and most importantly showing the client alternatives are a key part of the long-term relationship with the client.

Continuous education to the client can be a long-term benefit to the client/manager relationship. Often times the client hires a team, led by the project manager, because they are not knowledgeable about a topic. The article suggests using your expertise and starting from the beginning of the process explaining things at a high-level. It is important to detail and explain what things mean line-by-line.

When the project team presents a deliverable, it is key to take the time to educate the client on deliverable when can make it faster for decision-making. Six short steps can aid in successful presentation of deliverables:

  1. Start with short history of project highlights strategy and goals as well as what has been done to date.
  2. Explain what the deliverable is meant to do and how it will impact any downstream decisions.
  3. Present the deliverable thoroughly and with enthusiasm, covering the process behind the decision and variations that were discussed.
  4. Conclude presentation with a series of guiding questions
  5. Give client time to think and review before discussing
  6. Always receive formal feedback and follow-ups in writing

This isn’t what we asked for!!! We built it using your requirements!!!

I have experienced constant struggles between the business units and IT departments at work.  A businessperson feels they have been very explicit on what they need delivered regarding an IT solution to a business challenge.  The IT person feels they have captured all the relevant business requirements to deliver a great solution to help with business needs.  The solution is implemented and nobody is happy.  What just happened?


Unfortunately, I have been on both sides of this argument and there is no easy answer.  However, I think there is one constant that can help improve the quality of any IT project.  It starts and ends with relationships.  People have told me that it is all about the process.  “Plan the work and work the plan.”  As with any plan, pressure mounts due to time constraints.  People try to get through tasks to capture requirements, processes, testing approaches and etc.  People talk and share when they trust you and you take an interest in what they are doing.  Not only is it important to build these relationships within the project team, but also outside the project team.  Usually, a project team is asking a person to give more of their time in addition to their current role.  Knowing this, the project team needs to be as efficient as possible when capturing data and knowledge.


In the first article, How to Get Down with the IT Guys the author talks about how people with curiosity about the “other side” tend to make greater strides because they ask better questions.  I agree with this as well.  It puts a person in a place to ask why something has to be a certain way and gives people an opportunity to challenge themselves to see if something can be done differently to accomplish the ultimate goal.  In the second article, Building Relationships in Project Management, the author talks about knowing who the stakeholders are and managing their needs and expectations.  When running or working on a project, it is more than managing the tasks and timelines.  You have to manage and lead people.  These relationships are what lead to successful projects.


Where I work, the company has made a conscious effort to move business folks into the IT department to help with these relationships and to deliver improved solutions because business requirements are better captured.  In my opinion, the business experience has helped, but the relationships these people have throughout the organization is what is driving the improved success.  People are more comfortable with those they know and can converse with in the same “business language”.


I am curious to hear what measures your companies have taken to overcome the barriers between the business and IT departments.  In your experience, are there certain communication practices that work better than others do?  What are some of the processes your company uses to capture business requirements?