Too many 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 a fast and easy project. But, later in tuned out to be a stressful project for both Scopic team and the client, as the project was over budget and overdue.

Julia Please add sections that you think went right.

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, you mentioned “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 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.

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:I think to avoid such situation could help a careful attention to detail of a PM or the ones who make the requests assessment. In addition, a great idea is for someone with more experience to check the assessment file. The easiest is of course to describe in details what is included in the quote and what is not. So, that both customer and the team clearly understand the scope of task and no one can dispute it later on.

Such situations happen and at some point no matter how good you are, you just cannot avoid all unforeseen situations. In this case, you could simply deliver the code you made to client and let him test the functionality that coded other developers.

Also, why did you test the whole application?

Too many people involved in communication with the client.

Effective communication is a key to success – that is of course undoubtable truth. In our case, from the beginning customer had too many points of contact, which, from my point of view, is very inefficient. PM should try his best 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, from my point of view, it makes hard for the client to track who is doing what and with whom he should be communicating.

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 the PM. On the first place, because PM does not track projects progress anymore and cannot adequately evaluate the billing.

Date: 2016-03-03; view: 831