Too many were people involved in communication with the client.
Peeps Tree (Case Study by Julia Kolegova)
Project Scope:
The task was to finish the web application that was about 85% complete by external developers. Clients? requirements were simple and straightforward. From the beginning, it seemed that it would be an easy project. But, later it tuned out to be a stressful project for both Scopic team and the client, as the project was over budget and overdue.
Challenges:
Changed scope of work
On the estimation phase, Scopic team did not take into consideration possible issues with the inherited code. As a result, on the initial stage it was not agreed with the client that any work associated with the bug fix of the inherited code would be charged additionally.
In the estimation file, it was mentioned ?project and code analysis? task and it took the team 24 hours to complete it. Just putting ?code analysis?, from my point of view, is not descriptive enough. As it is not clear, what exactly is planned to be done within the scope of the task and client could easily dispute its ambiguous description.
On a later stage, when bugs with the inherited coded appeared. Client was not willing to cover extra fees for bug fixes. His argument was that the team had to provide him with the list of bugs in the beginning.
To keep the client comfortable with the service, the team had to fix the minor bugs ? which lead to additional costs and to the change of the project scope.
Solution:To avoid such situation could help a careful attention to details of a PM or the ones who make the assessments. In addition, it will be great for someone with more experience to review the final assessment file. Such ?experienced outside review? should help to ensure that no details are omitted and forgotten.
Then there is a need to carefully draft the final estimation file and in details describe what is included in the estimation of each task and what is not. So, that both the customer and the team clearly understand the scope of each task and no one can dispute it on a later stage.
Finally, a proper communication and documentation of what is happening or anticipated to happen.
Too many were people involved in communication with the client.
Effective communication is a key to success. In our case, from the beginning customer had too many points of contact, which, from my point of view, is very inefficient. One of the PM duties is to build the trustworthy relationship with the customer. Customer should feel that PM represents his interests within the development company. When there are, too many people involved in communication, clients intuitively prefer to communicate either with management or directly with the executers.
In Peeps Tree project client was in communication with:
1- Alex Habib (Sales and Marketing) ? This is my assumption. Because I did not find any records of it in basecamp or elsewhere else. But, I as he is responsible for sales. Most likely, he was the first who talked to the customer.
2- Alex S. ? he did the preliminary assessment of project requirements.
3- Stella. Alex introduced Stella to the client.
4- Stella introduced Lori.
5- When Lori took days off Diana was in communication with the client.
6- Developers
7- Ben ? when Lori was on a vacation
8- Vera
9- Tim discussed discounts with the client.
As a result, PM fails to build the trustworthy relationship with the customer. Customer tries to contact directly developers to fix bugs ? which is the worst thing that could happen to PM. On the first place, because PM starts facing issues with project tracking and cannot adequately evaluate/ track the billing.
Solution: Do not give to the client access to developers. PM should be the only point of contact. In case this is not possible, instead of Skype, you can use Slack for communication. In such case, all communication between team members and customer will be available to anyone at any time (privacy settings can be easily configured).
Miscommunication
It seems that PM does not spend enough time explaining methodology to the customer. Or explained it the way so that customer did not understand it. For people who have never worked with Gantt diagram or other project tracking tools, it takes time to recap how it all works. Quite often PM needs to explain to the customers the same things several times.
Also, customer avoided PM and talked directly to the developer. Developer instead of asking the customer to contact PM for all issues concerning bugs - fixed the bugs without informing PM. This seems to me a very serious communication gap.
Then, why did PM investigate new requests from the client in Jira? Wasn?t the PM the one who creates all tasks for developer and communicates with the client? Looks like PM was ignored. Again miscommunication issue.
Another poor communication occurred when developer was moved to a new project with high priority without informing PM about this fact.
Finally, seems like Diana ignored PM and assigned developer to a new project even though the PM said that the developer could not be assigned to new projects.
Solution: In any team, such miscommunication issues can happen. To minimize them you can determine the proper communication flows for project members and develop a checklist of what information (reports, status, etc) needs to be conveyed to project participants. The communication checklist should also have an associated schedule of when each information dissemination should occur. Besides, all team members should be aware what type of information should be handled only by PM. Also, you can use Slack or any other tool to record all written messages.