PM rescue kit: Most common fuck-ups on your project

Every PM has a lot to tell you about different fuck-ups on his projects. But why we share our fails so rarely? Of course, it is difficult to tell others about your failures, so we prefer to tell only funny stories or “one of my friends…”. We with my colleagues suggested to create the list of most common problems on our projects. I can’t hope it contains some new and fresh ideas but al least it should persuade you that you are not lonely in this world of failures.

Case 1: Client does not understand why the estimation we get after the Sprint 0 stage can differ from the initial stage estimation

Arggh…It seems that you discussed all the things in advance. You explained all the unclear points. But, you know…

The most common reasons of the budget to grow are:

• Initial stage estimation is a high-level estimation. Time spent on initial step is not enough to get the detailed vision of the project, but the result fits the goal, as by minimal time and money we give the Client the idea of the size of the project and rough budget, so the Client is able to make the decision – continue working on this project or make any changes to fit the budget, pause works, etc.
• During Analysis stage we spent time on getting into details and forming the complete view of the project. It allows us to make more precise predictions (but still they are not final for all the backlog).
• While studying the product team usually come across the functionality that is required, but was not mentioned before. (PM should provide the list of such functionality in particular project)
• Team can come up with some ideas of new functionality during the Analysis stage. (PM should provide the list of such functionality in particular project)
• Some tasks can be found more difficult while investigating all the details.
• Design is discussed and analyzed during the Analysis stage, so the estimation can differ a lot depending on the complexity of design.
• Initial estimation is created taking into account the following size of the team: 1 developer, 1 QA, 1 designer
• If the team size is bigger – costs are higher because of additional time on communications and project management. Creating products faster by increasing team size usually lead to additional costs.

How to rescue:

• Track the changes you make to the backlog – adding new tasks, the estimations of new tasks. Then you will be able to show that “additional scope” to the client.
• Your sales manager should not present the initial estimation which you give to the client during the presales as the final one.
• Track the time-consuming activities which were caused by the client. Show that log to him from time to time and try to get rid of this.

Case 2: Client does not understand why the costs are higher than he expected on the later stages of the project or on the final stage of the project.

This can be very unexpected. You are working on the project sprint by sprint…You are honest and open – client can see everything in your processes. And one day he asks: “Hey, we have already spent the budget we discussed with [sales manager name] last January…Why the product is not ready?” This can happen even if you have the dashboard with the planned budget and your client is looking on that every day.

Most common reasons are:

• New features were added – ask PM to provide the list of new features added during the development process and the time consumed for their development. PM should track the list of the new features in the Project budgeting document.
• Some tasks appeared more difficult than we expected – ask PM to provide information on the tasks which appeared more time consuming then we expected. Launch a call with the client and PM to discuss these tasks.
• There were some issues on the client side, which resulted in the additional time consumption from our side:
  • client did not provided the materials in time, that blocked the team from the development
  • too much time were spent on the communication – client had meetings every day with PM, long calls – ask PM to provide the information about that
  • if the server-side is developed on the Client’s side – changes in the API, delays in the API request delivery can cause our team additional time consumption

How to rescue:

Track changes, have the clear vision of the % functionality ready and % budget spent at any point of your project.

Case 3: The Client claims we are not meeting the deadline. And that is true(

Most common reasons for the delays on our side:

• some team members were ill/absent, the client was not warned
• developers were shared between projects
• we underestimated the tasks
• in the RnD projects – we underestimated the complexity of the new technology
• not experienced team, huge amount of juniors. I even had teams full of juniors. Sad, but it is rather common for outsource companies.
• new expertise field for the team
• infeasible deadline

Most common reasons for the delays on client side:

• the scope increased – PM should have the list of the changes made available
• delays with providing us the information critical for the development
• too many comments on the design – the design is not approved when the development starts
• client is not available to connect during some time
• if the API is developed on the clients side – delays with the API development

How to rescue:

• Notify client about the delays beforehand. It is always better you warn him, not he writes an angry email to your boss.
• Negotiate: cut the functionality, set the new deadline. But please, do no try to increase the team on the last stage of the project. I am sure you know why it won’t help.

Case 4: Client is not satisfied with the quality of the application ( he can find bugs/application is not working)

Kill the QA. Ok, seriously. Kill the client. No, I wanted to say the different thing. There is no common solution.But listen to the client. Let him speak and explain. Sometimes “it is not working at all” means that he can’t login, as he is using an out of date test credentials or the button is not looking like he expected.

Sometimes, the client is 100% right – the quality sucks. And you know there. The best option here is to admit, that this is right and propose the plan how you can improve it. It is better to talk about the solution, not about whose fault it was.

Case 5: The Client is not involved in the project as much as needed.

There is no chance you create a good product if your client is not involved in the project. He should be prepared, that if he wants to get a good result – he should spent not less than 10 hours a week on the application. The client (decision maker) should be ready to collaborate. We like clients who are constantly looking for better ways to solve problems.

How to rescue:

• Inform the client about the importance of being involved regularly in the project during the sales phase, not when you start sufferig from it. The Agile development process requires the Client to be present on the Sprint planning, demo meetings, backlog grooming meetings, some status calls, questions calls during the sprint.
• PM should communicate more actively
• Contract should contain the regulations of such cases for the client side

Case 6: The Client wants to increase the team to work “faster” in the end of the project

No, it won’t work. Adding new people when your project is going to hell will just make this process faster. Just believe me. Adding new people will take additional time from your existing team members on supporting these new people study the project. First time the person enters the project he is not bringing any positive value – he is bringing the negative value. That is ok, not not when your project is delayed.

Case 7: The Client says that we developed not what he wanted.

The first you question can be “How that can happen?” I can assure you that it can happen. Even if you work in a close cooperation with your client. Sometimes it is very difficult to find out what is happening inside his head.

How to rescue:

• Track all the discussions. Follow ups on the meetings are a must have. Write down everything.
• Talk to the client more. Get their opinion as early as possible.
• Do not position the client as an expert in mobile applications. He starts feeling responsible, as a result – nervous and can give some ridiculous comments.

Case 8: Client does not understand why we can’t make this change/task immediately. Why we can’t add tasks to the current sprint.

Agile methodology  is rather new and rarely our clients have an idea about that. That is why we need to spent some time “educating” them. Usually, this is done by the PM or consultant.

If the project is running, but the Client asks you the following trigger questions:

• Why we can’t change the priority of this task so they can put all aside and do it today? ( And you know that it is not once – he doeas it every sprint – tries to change the sprint backlog when the sprint is running)
• Why they do not take this task in the sprint? (the team planned the sprint according to their velocity – they can’t commit to the higher velocity – the simply will not manage to do that)
• I can’t tell you what is most important! All of these tasks are the major priority! We need to do them parallely!
• Why we are not just develop it all and then test it? Why do we need to test each task?

All these questions are the evidence that the client does not understands our processes.

How to rescue:

• Discuss with team how to present the development process to the client. Launch a call, play some process teaching games with the client. It can even work if you invite the client to the office to work for several days with the team.
• Explain to the client, that all the changes/additional tasks are not thrown away – they are implemented in the next sprints. The team has the limited resources, they have the velocity metrics which shows how much work they can do during the sprint.

Case 9: Client continues treating T&M project as the Fixed price project

In our projects we are not fixing scope. How we can fix price? If the client has some “budget limit” – he should be prepared that we would not be able to implement all the tasks. Also, if the PM has the fixed price project with fixed scope – he does not allow any changes into the scope list, as his team commits to the price in the beginning of the project when they estimate some certain list with the certain level of detalization. In T&M projects the changes are welcomed, as this is the core thing in the agile development – implement, check, improve. but all the changes are adding costs.

Steps:

• PM should have the clear backlog document with the estimations and rough planning. So the client would fill confident about the project process.
• Account/sales manager should explain that the estimation client gets on the initial phase is a rough one. As the backlog changes – the estimation changes too. It can be lover or higher – depending on the changes in the fuctionality and if our prognosis of the estimation is true.

Case 10: Not enough information for the PM on the start of the project

PM suffers from the lack of innformation on the initial project phase

Prevent:

• Launch initial set up meetings with PM. Sales manager should forward all the info he has about the project to PM.
• Set up meetings with client – presenting PM, first discussions ( the ideal time to discuss processes and how we work once more)

Case 11: Working with R&D project: the result of the research is negative

On the certain stage of development while working on the R&D task developers find out that we can’t implement the needed functionality (technical restrictions). R&D projects are always risky for us, as it is difficult for the client to understand that we can’t guarantee that the results of the research are positive. If we can guarantee the results – it is not an R&D approach.

What we can do:

• On the initial stages of the project discuss with he client that the results can be negative. PM should prepare the “risk management’ plan – what we will do in that case: try some other options, decline the functionality, design the new functionality in the frames of the technology restrictions we discovered. If the client see all the options in the beginning – we would not have the issues of the “I didn’t realize that” in the end.
• PM should provide the client the report on  the investigation – the reasons why there are some issues/restrictions/limits. There should be some links to the evidence/data exports/etc.

Case 12: Issues with the third-party service we use in the application/for the development

We are often using some third-party services in our applications: google, facebook, twitter APIs, salesforce integration, etc.
All these products are developed by the separate companies, that is why we can’t guarantee their 24/7 work.

Steps:

• PM should discuss with the client on the initial stages of the project that we can’t guarantee the third-party services working
• PM should approve with the client any third-party service used in the development.
• Don’t forget about adding that to your risks table

Case 13: Delay of the project is on our side. New OS version is released and client insist on supporting this new version because of the delay from our side.

Everything was perfect – we almost managed to meet deadline ( a month of delay is ok?). And at that moment we found out that new version of OS is coming. Of course, you can’t say that this is “out of a sudden”, but we were so busy with our project that didn’t even realize whether is was spring or summer outside. We were working day and night. And then this new OS was going to appear and our client insisted on the application release which supports this new version.

Of course, it depends, but usually it is better to release what you have and then implement some new UI design/support/etc. Especially, when you team had a long way developing this version.

Case 14: The application can’t go through the Apple reviewers – they reject it every time.

I had this case in one of my projects. And this application was never released. It was an epic fail. The reason was that we were selling content in the application and the client refused to use the in-app purchase. It was my fault – I had to investigate the case deeper and foresee that our customer can refuse to implement in-app purchase and discuss that in the beginning of the project.

How to rescue:

If your application was rejected – all you can do is to follow the Apple comments and guidelines, make changes and upload it once more.

To prevent such issues – create the project start check-list and on the first place put – check the Apple publishing guidelines to find out if your application is not breaking their rules. There are a lot of applications dealing with selling/buying something – services products. etc.

It is not the full list of the issues, I had some specific for our company on the list. But these are some common problems for the mobile applications developers.