User Relationships with Mistrust, Doubt and Fear Drain Your Team’s Energy and Creativity
By now, l’ve learned one thing for sure. Project management does not give a receipt of guaranteed success. It takes effort to manage people, align their goals and focus their efforts to achieve a common objective. People are susceptible to moods, interests, biology, hormones, cultures, economics, weather, and even the moon. For this reasons the difference between success and failure is often much more subtle than executing with perfection some steps. Stakeholders Main Page
This first post, actually the first of a series, will start with one factor I have seen strongly influencing the final result; users. My experience is mainly in technology-related projects, new systems, integrations, etc. In all these projects, as much as I can remember, the top critical factor has always been managing user expectations.
The User Relationship Situation
On one case, we had a relatively large project being executed in a week matrix organization. It was related to a new system and I was part of the steering committee. The initiation phase was behind us and there was a board decision to go on with planning. The team had already worked together in the past. There had been some conflicts as well; conflicts related to a feature that the users reported as a bug but from the technical team, it was treated as new request. There were big discussions that produced very little value. In the end, the feature was developed but it left some bad blood among the team members.
The heavy mood was immediately visible during the requirements collection phase. Meetings resembled court rooms. On one side, business users were laying down requirements to be as broad, interpretable and as inclusive as possible. On the other side, architects and business analysts were asking details to a ridiculous level. The drama went on without an agreement. It burned all the time of the tasks, including any duration buffers we had. Suggestions were looked upon with doubt resulting in tiring and exhaustive sessions with no end in sight. If this was the requirements collection phase, we could only imagine what the situation would be during testing and acceptance.
So how do you work around such a situation when every sign, and your guts, are telling that this is headed toward a disaster? We tried two measures before getting to the radical step of changing some project team members. I always make all possible efforts to avoid changing team members. Changing team members often creates more damage than benefits. Especially if you work in an organization and you have to work again with these people.
The User Realtionship Solution
First we clearly stated, “Huston, we have a problem” and openly told the team that this was not working out. Their “cover my back” attitude and reluctance to take ownership and responsibility was jeopardizing the project. With the most problematic team members, we conducted one-to-one meetings to listen to their thoughts on how to move on and leave the past in the past.
Second, we had the team spend more time together during the day and at least once a week we gathered just for a drink. We went to the line managers and asked for dedicated project days. This prevented the people working on the project from switching among project and non-project tasks within the same day We were aiming for focus.
In the end it went fine, not great, just fine. We managed to finish within budget and scope, with some deviation from the time line. I would say we dodged a big risk.
The lesson learned was simple; resolve the conflicts or avoid them, as nobody wins endless conflict. Even if you gain some ground in the short term and the power balance is on your but in the end you pay it back and very often with interest. The best result is to see a considerable change in the attitude of the team.
It is so much easier to work in an environment of trust. Doubts and fears drain your energy and creativity. It is your choice where to invest your finite energies. You do something great with your users, or waste those energies going on the attack.
You learn all of those skills in our project management basics courses. Take a look at the basics course in your specialty.
[button link=”http://220.127.116.11/~jwkdwgmy/it-project-basics-111/” style=”info” color=”red” window=”yes”]IT Projects[/button]
[button link=”http://18.104.22.168/~jwkdwgmy/project-management-basics/” size=”medium” style=”info” color=”#1e14a8″ border=”#940940″ window=”yes”]Business[/button]
[button link=”http://22.214.171.124/~jwkdwgmy/construction-project-basics-121/” style=”info” color=”red” window=”yes” bg_color=”00000000″]Construction[/button]
[button link=”http://126.96.36.199/~jwkdwgmy/healthcare-project-basics-131-2/” style=”info” color=”#1e14a8″ window=”yes” bg_color=”00000000″]Healthcare[/button]
[button link=”http://188.8.131.52/~jwkdwgmy/client-project-management/” style=”info” color=”red” window=”yes” bg_color=”00000000″]Client Projects[/button]