Whether at university, in a textbook or during an online course, theory always differs from reality. This is true across many disciplines including project management and product development.
In this article, we want to debunk some of the project management techniques and methods that may work in theory, but based on Flux’s years of experience, don’t really apply in real cases. Some are more relevant for clients and others speak to PMs. So we divided our list accordingly. And with that in mind, let’s dive in!
Project Management: What Clients Should Know
Faster and cheaper is not really what you should seek as a client
In most cases, when we decide to build a product or want to maintain it, as a client we look for a quick fix. So we seek the fastest and cheapest solutions.
Yes, it is always great to have a fast and cheap solution. However, what is the value behind it?
Engineering teams hate these requests not only because they don’t want to be hurried or underpaid, but mainly because they know that fast solutions mostly hurt the product in the long run. Specifically, they harm the code structure by adding a lot of regression cases. In order to avoid that, the team needs to first brainstorm and highlight all pros and cons of the solution.
There will be cases for sure when the team will find a quick solution with no bad impact. However, even the quickest fix takes more than 15 mins. So try to not request 15 min fixes from your tech team.
The main reason why it takes a bit longer is for the simple reason that finding a solution to any given problem requires thought and then application. Thinking and designing solutions are the core base, which makes products sustainable and expandable.
Fixed project scope and budget are not the best way to succeed
Yes, planning is important. However, doing that for software development is not as easy as most of us think. While working with products that had a fixed scope and cost as PMs, we always faced the case where during the development process a lot of things changed. This is not because the tech team did a bad job planning, but because of the nature of the process. Like anything you build from scratch, as a client you always see the results and often you want to tweak, adjust, shift course, and improve. All this leads to changes that were unforeseen at the beginning.
Thus, fixed budget and scope sometimes become blockers for the owners but not for the suppliers, because it deprives them of their opportunity to see the result and freely comment and change.
That’s why usually we recommend our partners to adapt an Agile mindset and approach to development. This will help build the pre-planned MVP while at the same time give the opportunity to develop the product properly. Even if you weren’t thinking about the cases beforehand and didn’t pre-plan, Agile always helps you stay flexible but focused. You can always change the plan and move forward with short sprints.
The client isn’t always right
Whoever said the client is always right, probably thought they were doing the best for their product but were completely off course. A product can still be customer-centric, the stakeholders can still be very happy, the PM can still be good at their job, even if the client isn’t considered to be right at all times. (It happens.) We all get stuff wrong sometimes, especially when we’re in untested waters. Typically, this is the case for most clients since they’re not building a product they’ve successfully built before.
It’s vital for a PM to understand the product and the industry. This way they can spot when the client is thinking of going in a direction that’s not going to bring the value they think it will. At that point, a good PM will suggest alternatives, develop plans for the future, offer new cool features that foster growth or increase retention (depending on what the goal is.)
It’s important to rely on your PM when they adapt your requests to do right by the product. PMs wear many hats. Throughout the project they will likely take on the role of product advisor, data analyst, growth specialist, product owner and much more.
Tip for PMs to know where you’re at in terms of knowledge and trust: It usually works to ask yourself how long would you and the team last if the client was lost on an inhabited island. This way, you can define for yourself how well you know the goals of the product and whether the product would fail if you had to make all the decisions.
Project Management: A PMs Guide to Success
A meticulously-managed team isn’t always a well-managed team
Bottom line: if you’re micromanaging, you won’t get far. As PM, you can’t possibly handle all of your responsibilities if you’re constantly checking on someone to see whether they’re doing their job. Therefore, getting your team to be as self-organized as possible is key to you being able to focus on your tasks..
As long as everybody always knows what they need to do, the order of tasks and timeframes, you should be fine. If they have questions, they’ll come to you. When something’s going wrong, they’ll come to you. And everything’s going great, they might still come to you, but that’s just because they love you so much. 🙂
Tips to know where you’re at in terms of self-organization: Ask your team to hold a discussion about some topic and present the result with action points. Alternatively, conduct a stand up without you being present. Or try not asking any questions about the release on a release day and see how it goes. (n.b. Please don’t let the release fail because of this, if you see it’s not going well, ping them).
Teamwork isn’t always the answer
Having teamwork as a skill has been popularized so much that we feel like that’s always the best way to go. But what if you have a team member who’s used to having other team members guide you in a scenario where they have to work on their own? Sometimes everyone has to focus on their own tasks. It happens. And each team member should be prepared for this.
Teamwork will always be an important part of any team member’s skillset, but the ability to work independently is just as important. Undervaluing individual achievements pushes team members to be dependent on each other. If a PM appreciates and supports individual efforts as much as team efforts, team members will start to value this skill themselves. Beware not to create a competitive atmosphere..
Tip to keep the balance between independent work and teamwork without competition: Whenever possible, allocate extra time to work on a feature that’s a bit higher than their technical level, during which the team member can figure out how to do something by investigating instead of asking around.
Success measurements don’t always mirror reality
Have you ever had a stakeholder judge the product’s success purely based on KPIs? It hurts, doesn’t it? KPIs are essential for measuring success, but in the chaotic world that we live in, we simply can’t rely on them alone, however, well they might have been defined and calculated.
If a burndown chart looks good, it doesn’t necessarily mean that the sprint has been successful and vice versa. If the number of bugs resulting from a feature is low, it doesn’t necessarily mean that the feature was well-implemented and vice versa. Hundreds of such examples prove that statistics, numbers, and calculations are great, yes, but the human factor, the case specificity, and the product specificities matter just as much. We always need to keep in mind that the world is colorful and measurements are black and white.
Tip to keep balance between global measurements and case-specific ones: Whenever anything is seen as an outlier, analyze it fully, bring out all the issues, discuss the reasons, and see if they fall under your measurements or not. Maybe you need to update your measurements. Maybe it was an isolated case? For some products, it’s a good idea to create a method of outlier analysis. This technique has helped out a lot at Flux and has solved a lot of issues.
You heard from us. Now we want to hear from you.
Whether as a client or a PM we hope these small pieces of wisdom help you understand the way project management and product development work in real life. It’s an incredibly fun journey with room for creativity just so long as you keep in mind the practical scenarios we presented above.
Let us know in the comments what project management methods worked for you. What myths have you debunked? Looking forward to reading all the PM tales and client stories.
