It’s been quite a while since talked about our failures here. Since then, we've made some new mistakes but used each of them as an opportunity to grow and we would like to share with you the lessons we learned. In Netguru, we strive to deliver the best work possible, but, we admit, we sometimes fail and, as long as we don’t make the same mistake twice, we accept it as a part of the learning curve.
Today, I’d like to tell you about the popular mistakes a PM can make (and we know because we’ve made them all) so that you can avoid them in your daily work.
# You don’t need to track budget in SCRUM
This is actually one of the misconceptions we try to warn our PM’s about from the very beginning of their time in Netguru. The fact that we work in the Time and Material model and iterations that in most cases cost the same amount of money and we meet at regular Sprint Reviews with Clients doesn’t mean that we can skip tracking budget altogether.
As a Project Manager, one of our core responsibilities is to help the Client understand not only the progress we’re making in the project but also the amount of money that has been spent and the money that still needs to be invested to deliver features that will bring value to our users. This knowledge enables the Client to calculate the ROI on specific features or iterations and plays a key role in supporting the Client with strategic decisions about the product.
# It’s the Client’s decision
This mistake is quite tricky and it’s an easy pitfall to fall into. It is true that we work with our Product Owners (aka Clients) who ultimately have the final say regarding the scope of the product and priorities we follow. On the other hand, we need to remember that we have a unique perspective on the product, which helps to detect the blind spots in the Client's vision and consult the Client on the future direction of the project.
It’s sometimes easy to give up and say “I’ve tried but they decided otherwise, it’s the Client’s decision so let’s do it”, but we can’t give up so easily. Using data, the knowledge of market trends, and good practices, we can start a conversation with our Client and help them make the best decisions in the current circumstances.
# I’m not a PO, I don’t need to know the product that well
In our projects, we work with great Product Owners, making sure their vision is accurately translated into reality. While focusing on productivity and removing the impediments with the team, it is sometimes easy to get lost in the features we implemented, how they actually fit in the product, and whether they meet the user’s needs. But it’s crucial for us to know the market and product well to be able to advise our clients in choosing the most valuable features to work on and help teams work as efficiently as possible.
It’s crucial to understand not only how the product works, what the user’s flows and possible blockers are, but also what the business value of the product is and what the goals we want to accomplish are. Only with this knowledge can we give our clients comprehensive advice and help teams achieve the best performance possible.
# There is such a thing as overcommunication
Communication with our Clients and teams is one of the most important responsibilities of a Project Manager as well as one of the activities we use most often in our daily work. Hence, we keep our communication transparent, to the point, and as clear as possible so that all parties can get on the same page quickly.
But there are times when we assume that since something was said once, everybody remembers it, and we don’t really need to communicate it again, which most likely is a mistake. In a PM’s work, there is no such thing as over-communication. You need to make sure that all information is clear and delivered on time even if it means summarizing every discussion in writing and making sure that their outcomes and next steps are clear to everyone. It creates trust between partners and prevents some unfortunate assumptions and expectations.
# It is not my responsibility
We work with many people on a daily basis: Clients, developers, QAs, Account Managers, the Finance team, and many many more to make sure our projects are successful. Each of the roles I listed plays a big part in how we manage projects and ensure their effective delivery. However, at times the boundaries between the responsibilities are vague or overlap. In this kind of setup, especially if we’re busy or a bit tired, it’s easy to just say “this is not my responsibility” and move on. Even though it might be true in some cases, we still need to remember that we work as a team and we share the responsibility for delivering the project successfully. We encourage others to take ownership and we help facilitate decision-making, but we also need to flag up the risks and make sure they are mitigated even if they are not our direct responsibility.
Let us know about mistakes you’ve learned from.