50 shades of PM in the most difficult project

Valeriya Yakovenko, Head of Project Management Department at eKreative

Transcript

1. 50 Shades of PM Valeriya Yakovenko
2. Quick intro: - 4.5 years of experience as a PM - Head of PM department at eKreative - Development Manager at MapaMagic - Teacher of PM course at GeekHub - FLEX Alumni - Love psychology and self-development - Topographic dumbhead, I can easily walk around London but will get lost in Kiev by myself
3. About 2 years ago we received a proposal for a very interesting project... It was a great opportunity for us our company and for me personally. A social network app for beauty bloggers!
4. What could possibly go wrong? EVERYTHING. We did proper planning and kick off of the project, we had good developers in the team, the client seemed to have a great business idea etc. But things started to get out of hand at the very beginning...
5. Project cost Our partner had agreed to a certain price with the client before we actually quoted on the project. It turned out that the budget was smaller than what we needed and we had to make a discount. So, it meant I had to be very careful about any scope creeps and change requests.
6. Deadline The client had a very tight deadline. He actually had paid for marketing which tied to deadline but he didn’t tell us about it. Lesson learned, you should always check this with the client what he is planning for the project release.
7. Designs We didn't get all the designs at one go... It meant that I had to keep the developers busy not to lose time. It was a battle of getting the design screen by screen and negotiations about the additional features that started to creep in.
8. Estimating The client kept asking for estimates on new features. He tried to add features to phase 1, and also plan phase 2 and 3 simultaneously. After some time I had to put this to an end as it was very difficult to distract the team to quote on each individual feature.
9. Interrelated Deadlines Phases 2 and 3 were planned to be delivered right after phase 1. Since we were not hitting the deadline for phase 1, phases 2 and 3 would now have to be shifted as well. It taught me not to commit to deadlines on consequent phases, when the scope for 1st phase was not locked down.
10. App overloaded with features Client wanted to add as many "cool" features as possible. He constantly explored other social networks and wanted to borrow ideas from there. Well, everywhere! We were trying to explain to him that sometimes it’s better to have less but more consistent.
11. Managerial Culture The manager from our partner's side had just joined the team. His managerial culture was quite harsh at the time. He put pressure on the team to "get the most out of it". We were very accommodating, but there comes a time when you have to stop this kind of attitude.
12. More doesn’t mean better The client asked to add more people on the project thinking that it would speed up the development. However, we actually now had to spend more time on communication. Be realistic about the value and output of adding more people to the team. It may not be worth it.
13. Overtimes Because of the necessity to speed up the development we had to ask our team to work overtime. A LOT. This affected their state as it was summer at the time and they had to spend evenings and weekends working. Client said he could pay more, but we couldn’t go on working like that. So I had to stand up for the team.
14. Bugs Developers were getting tired of the constant overtimes, pressure and reminder of very close deadlines. The stress had its impact and they started to make some obvious mistakes. We had to face the reality. Neglecting the state of the team you’re neglecting the quality.
15. System scaling The client was convinced he'd get half a million users in 1 week after the release. We found out about the size of the planned user base only at the end of phase 1. Although it sounded ridiculous, the client thought it would come true.
16. User base location The client didn't tell us that his user base was located at a different country than where he was from, and we made a wrong assumption when choosing a region on AWS. We ended up moving the live server. This taught me that it is very important not to make assumptions that seem to be very obvious.
17. Annual leave The deadline for one of the biggest releases was in summer. I booked the trip BEFORE I knew there would be a release and client didn’t want to change the date. A different PM had to handle the release on a day when she herself was leaving for vacation. She had to catch her flight… SO I came back from vacation to find out the the deadline was missed.
18. App Store rejection Our very first submitted build was rejected because of a very stupid reason. I found out about this when I was away on a conference for a different client in London. I was very upset. There is no good time to find out the bad news. This taught me to get past the emotions and to focus only on results.
19. Project of many firsts - First time working with a big team - Phase 1 and 2 were developed simultaneously and then had to be merged together - Load testing, video streaming in different qualities, split payment flow, monetisation using several 3rd party services - Issues with iOS core etc.
20. You keep going It's one of those projects when you feel that no matter how hard you're trying to manage it well, the client still cannot learn to set reasonable expectations. The team makes mistakes. The time estimates turn out to be wrong. It's the project when all you have to do is be very flexible to make it move forward.
21. 50 Shades of PM This was a project when I truly understood how many shades a good PM should have. It taught me that there ALWAYS would be things going out of hand. You just need to be prepared to deal with them.
22. Questions?