Sense of team is important on any and every project. This is the first of several posts that provide some tips and techniques that I have personally used, or that I have seen used, to develop a strong working relationship between my firm’s consulting staff and the client’s end-users.
As a consultant for over 30 years, it’s been my experience that projects which are controlled by the business (end-user organization) are the most successful projects. When business can articulate its requirements, deadlines, and usability factors with specificity and decisiveness, project execution is better all the way around. In the early days of my career, when IT had substantial sway over how the look-and-feel of systems and how the systems would work, we were successful in delivering systems in a workable fashion, but seldom to business satisfaction.
Given that, the IT consulting firm or internal IT department still has tremendous responsibility to support the business staff in delivering their project. Business should control the project, IT should facilitate. This is where teamwork among the IT and business staff becomes paramount to eventual project success. The challenge for both business and IT is in striking the correct balance in the relationships among the teams. On the one hand, too close a camaraderie between individuals on the teams can cloud judgment when hard decisions need to be made. On the other hand, too much formality or contrived walls between the two teams can stifle creativity and result in a poorer solution.
Looking at the situation from the consulting perspective, the ideal situation is to have a knowledgeable user base who are not afraid to offer their opinions, and who are willing to roll up their sleeves and work alongside the consultant team to define and design the solution that they want. The challenge for the consultant (or internal IT team, for that matter) is that while they develop systems for a living, the business staff assigned to them for the project duration has seldom (if ever) done this before. I’ve often thought after the project is complete, “I would love to do this project all over again with the same users, but starting with the knowledge that they have at the end of the project.”
Here are some of those tips and techniques to begin using immediately in the opening days of the project:
- At the beginning of the project, before you even conduct your first requirements gathering session (also referred to as a Joint Application Design session, or JAD), spend some time working with the users, helping them to understand what will occur during the JAD sessions, and what will be the expected outcome of the JADs. Build this initiation period into the schedule.
- Conduct one or more “mock” JAD sessions with all of the end-users present. Make the JADs completely nonthreatening, and encourage participation by each person.
- Become familiar with the business’s policies and procedures documentation. When the users see that your staff is referring to their documentation, and soliciting questions from them to gain understanding of their business, your team’s credibility is increased in their eyes. They are more likely to trust you early, and believe that you sincerely have their best interests at heart.
- Go slowly. In conducting the “mock” JADs, use as your example a functional area for which you will be gathering requirements. Explain to the users that you will be much more deliberate in these first sessions so that they can learn the process thoroughly and understand the expected end results of their contributions to the JADs.
- Use an overhead projector, or some other medium, to publicly document the results of your requirements gathering sessions as you proceed through the sessions. The users see what you are documenting as you conduct the session. Allow the users to correct your input. If their input is off the mark, enter into a discussion with them using a questioning process to allow them to derive a better conclusion. Create a safe environment for the participants, showing them that you will rely on their contributions to the process. After all, it’s their system.
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