Sense of team is important on any and every project. In Part 1, I shared some tips and techniques to begin using immediately in the opening days of an IT systems project to develop a strong working relationship between the consulting firm’s IT staff (or similarly, an organization’s internal IT staff) and the client’s end-users. When that relationship and bond of trust is developed early, it carries on throughout the project to successful system implementation.
In this post, I provide additional tips and techniques that I have personally used, or that I have seen used, on projects to continue nurturing that sense of team and building towards a stronger probability of success:
- Celebrate every small win. For example, when the requirements sessions are complete for a system function, stop working and bring in ice cream and cake. No one can refuse ice cream and cake. When a major activity has been successfully completed, have a major celebration. On some of my projects, my teams have opted for an evening of bowling or billiards, or a night at the ball game. One caution if you are managing a project on behalf of a consulting firm – be aware of any restrictions that the business may have about its staff accepting a benefit from the consultant, or even the appearance of a benefit. That does not mean that you cancel the celebration or celebrate with your team only; but it may require finding a venue in which all can participate if they are required to pay their own way (hence the bowling, billiards, and ball games).
- Always do your homework. Don’t be afraid to call ad hoc meetings to ask your end-users’ input regarding something about which you are not clear. When they see that you value them as contributing members of the team, they will be much more likely to respond. People like to be needed. Need them.
- Never argue, no matter how inane a client team member’s contribution appears to be. Listen gracefully, ask lots of questions, and if you truly believe that the end-user is incorrect, help him come to that conclusion on his own. The countless hours wasted by consulting team arguing with their clients over the meaning of a requirement, and the bad will that often results, have cost countless projects countless hours and missed deadlines. “He said, she said” is fruitless. Document requirements, agreements, and minutes of meetings as accurately as you can, with the understanding that regardless of how well you document, there will still be areas of misunderstanding. But let me let me let you in on a little secret: when it comes to functional requirements specifications, my experience is that more than 80% of the time the end-user is correct. So shut up, swallow your pride, and make the change that the user requested (within limits; see the following bullet). It will go better for you and the project in the long run.
- If the misunderstanding is small, and especially if the issue is in a “gray” area – eat it. In fact, eat all of the small issues, even if you can “prove” that the client is in the wrong. (The fact is, that accepting such changes early in the project is often inconsequential). However, let the client know graciously that you are accepting responsibility for the issue. Then when that big, expensive issue hits the project, the client will be much more tolerant and accepting of responsibility when you provide the supporting data, especially when the client is reminded that you have “eaten” so many of the previous issues.
- Clearly there are times when the client staff member is the one who misunderstood. Allow her to save face. I learned this lesson the hard way when I was managing a project that my firm was implementing for the State of Hawaii. The state Project Manager, a wonderful Japanese-American man, took me aside and tactfully showed me how my “mainland ways” of confronting issues were shutting down his staff’s input. He then taught me face-saving ways to challenge his staff and get my point across in a much more acceptable manner. I know that his management of me helped our project progress with few issues, resulting in a very successful implementation.
It really does come down to the people issues – the human aspects of project management. That project schedule that your team so painstakingly created can “go off the rails” with poor client relationships. But it can be accelerated, and the chance for success is greater when your teams work well together.
www.ElitePMStrategies.com • The Human Aspects of Project Management • Copyright ©2013-2014. All rights reserved.
Permission to reprint all or part of this article in your magazine, e-zine, website, blog, or organization newsletter is hereby GRANTED, provided: 1. You give full attribution to the author; 2. The website link to www.ElitePMStrategies.com is clickable (LIVE), and 3. You leave all details intact (i.e. links, author's names etc.).
Latest posts by Merv Jersak (see all)
- The Olympics of Project Management – Control and Balance - February 12, 2014
- The Olympics of Project Management – Unstoppable Performance - February 11, 2014
- The Olympics of Project Management – Competing with the “Big Guys” - February 10, 2014