There is a lot you, as a PM, can do to make sure your team is successful in delivering the product you are working on. Taking full ownership of the timeline, budget, risks and a consulting mindset are just some of the ideas I want to share with you. You can be sure that the PM role can be as vital to a project’s success as skilled developers and insightful QAs. In this article I will share with you tips that helped us successfully deliver a working MVP for one of our clients. Enjoy!
A while ago we had an internal presentation on different approaches to Risk Management. One of the exercises I learned about has completely changed the way I look at risks - I’m talking about a Pre-Mortem. For those of you who haven’t heard about it, it’s basically an exercise during which (together with your client) you try to visualize all possible doomsday scenarios for your project before it even kicks off. Based on that, you list the most important ones and you come up with mitigation plans to either avoid or better manage them. Once done well, you don’t really need any fancy and complicated risk-tracking tools or processes - when you know what can go wrong from the beginning, you simply figure out ways to monitor these areas on a daily basis and make it a part of your project’s life cycle rituals. Don’t ignore the risks you have named - they will happen, accept them and deal with them. Make sure you are as ready as possible to tackle them when they surface.
In the project I have in mind we have listed 4 most important risks:
In every project, whether you like it or not, you need to be aware of each $ or euro your client can spend. It is even more important in a fixed-budget project. What I highly recommend it so try to think about it as your own money and make your team feel the same way about it. It will help you make conscious decisions - you know what your goals are, now you have to be able to calculate how much you can spend to make those goals happen. What I did was, I prepared a very simple budget tracking spreadsheet based on our usual rates and, from the first days of our project, I knew for how long we could actually plan any work. You know right away when you will run out of money and it immediately helps you better organise your priorities and cut the scope that is not absolutely necessary to achieve the goals of the MVP you are building. Unfortunately, you can’t have it all - extensive scope and limited budget don’t work together. Never. So do the calculations, make sure your client is aware of them, make sure the team knows how much money we can afford to spend each month, and how to best spend it. The highlight for me was when the team started asking me during the planning or refinement sessions “Aga, how much money do we still have?” - again, treat it as your own budget and it will make a huge difference.
Based on the specific project I have in mind, I focused on the fixed budget scenario but, of course, this approach is also useful if you work in time & material setup. It’s always good to know how much money our clients actually spend and how we can advise them to make it money well spent.
One of the risks we ranked as the most probable ones related to the core feature of the MVP that seemed a bit challenging, tricky, and completely new in our company’s portfolio. We almost slipped on this one as it came back to us right in the beginning of the development phase of the project. What I can highly recommend you do right after you agree this is one of the high risk items on your list, is to agree with your client to book some of the development team’s time to prepare a technical Proof of Concept to get the direction in which you want to develop given feature and see if and how to approach it to make it viable. It can be considered a mini-project within the project. Once you get the results, also assess the risks - are we sure we can do it? If there is a high risk we can’t do it - is the client willing to go with it either way? A PoC gives you a huge advantage and relieves some stress related to uncertainty. We failed to do a serious PoC right before the project kicked off but we did it in the beginning of the development phase and it was one of the first things we planned for Phase Two of the project - learning from your mistakes at its best.
As PMs we are responsible for overseeing the project’s progress and making sure we act if something seems off. What I did in this specific project was a little more than that. Together with the team we prepared a timeline that was based on the sprint goals we wanted to achieve by the end of a given sprint. They were user-centered, not very strict (so it gave us some flexibility when we were planning specific features that should go into the sprint), and they were a direction for us throughout the scope, until the release of the MVP. It was rather simple: we sat down and prepared a timeline based on increments of working features we aimed to deliver every 2 weeks (that’s how long our sprints were). It really helps you visualize how much you can actually accomplish vs the time you have left. It was a base for many negotiations and discussions with our client. Like I mentioned, you can’t have a limited budget and unlimited scope (I’ve never seen it work). So what you need to do is stay focused on the MVP goals and your users - anything that is not aligned with this must go. Keep this plan simple to follow and update it constantly with the team and your client so everyone is on the same page. It really helps to see that by the sprint 5 you want the users to be able to do XYZ in the app - so after every sprint you are sure there will be new value for them and you will not end up with 5 features started but no visible user value delivered.
Nobody likes it but if you are in a similar setup as the one I am describing here, you need to make sure you gather the team pretty often to do re-estimations of the scope you still have ahead of you before the deadline. There are so many factors in the constantly changing environment we work in that an estimate done 3 weeks ago can easily be obsolete and wrong now. We made sure this was one of the rituals we followed regularly, just like daily standups, planning sessions, and reviews with our client. At some point, the team was reminding me that e.g. given some recent timeline changes, we should definitely dive into the estimates again. I consider this a PM success when the team is even more eager than you to keep an eye on the progress - after all, it’s a team effort and we’re all in this together. Make sure your team understands the great value behind tracking progress and getting better at estimating the effort needed to develop the product. They will thank you one day.
We knew we were time limited (given how long the budget would last) but we actually never had any strict deadlines from our client. Seems nice, huh? Well, yes and no. At some point we came to a conclusion that we should come up with a deadline on our own, sooner than before the whole budget would run out. It made us even more focused and disciplined. It’s challenging to give yourself less time than you have in reality but creating a similar time (and money) buffer is a really good move in case of some surprise risk elements you were not able to detect. Worst case scenario - you need more time to deliver the MVP (but you are sure you have it), best case scenario - you deliver the MVP to the users sooner and you can already start planning a Phase 2 and what to do with the money you saved your client. Luckily for us, the second scenario came to life.
What you can do, as a PM, is make sure together with the team that you take as much ownership of the product as possible. Remember that you are the experts and you know what you’re doing - make sure you spot every opportunity to show that to your client. Consult and advise on a daily basis - use your personal experience to advise against ideas you know will most likely fail, discuss and adjust the priorities according to the current situation, and don’t be afraid to challenge your clients - many times they may need a second opinion and someone who disagrees with them for the overall benefit of their product.
One of the core pillars here would be proactive and transparent communication, both within the team and with your client. Communicate your progress and obstacles you meet on a daily basis, be transparent, and don’t limit yourself to official scrum events to discuss important issues. When you manage to make this everybody’s priority, the whole team will work as a super smoothly operating machine letting everyone know what is going on exactly when it’s needed.
All of the examples above show how much you, as a Project Manager, can do to positively influence your team, your client, and their product. Let me sum them up for you in a short list:
It is often tough, especially when something goes sideways or when your client is stubborn and won’t listen to good advice on your end. Nonetheless, don’t stop and work towards better project management on a daily basis. As you can see, there is a lot you can do that will have an effect on the project’s success. Get creative and start improving!