How do we decide what is important in a project when everything is?
I found that on projects, most of the time everything is important, depending on who you ask. When I think that I managed to reach a common ground with someone from product, I find that there are other things to be taken into account from a technical perspective. So in the end, all seems just as important.
So how do we reach a result in an appropriate amount of time to market?
Compile all requirements in one place
This is something that should happen naturally, but it is worth mentioning. If we have no one to gather these, but even in case we do, we should still take notes as to what the customer needs and/or wants.
In these meetings, get ready and ask plenty of questions. While doing so, pay attention to what the customer or stakeholder reacts more passionately or aggressively, and it will be easier to know what to push on in later MVP negotiations.
Identify what carries the highest value and prioritize
In the previous step, I highlighted that we have to keep an eye on what the customer reacts more passionately in our requirements meetings. Those are the things that could represent some of the features that are seen as the highest value for them. And sometimes, that might be the case, while other times, it would only be something that they fancy to have.
We have to work on understanding why is that valuable to them.
In addition to what the customers themselves point out as being important or essential, we can use our and our team mates experience to identify some other features.
Based on these, prioritize, prioritize, prioritize.
Identify what needs to be done from a technical perspective
Whenever possible, we should include someone technical. Even if some on you readers are from a technical background, technology is like a living organism, it evolves constantly and is in constant change. What was done a few months or years back are yesterday’s news and should not be used as basis for the technical consultancy we should provide to our clients.
The technical team mates should have the necessary experience to give us the needed expertise.
Some of the technical needs will be clear from the initial meetings, while other will need to be discussed afterwards.
We should discuss openly with the technical people and see what is essential from a technical perspective and again, prioritise.
Also, at some point, have everyone in the same room – physical, preferable, or at least virtual, using some communication tools.
Identify dependencies and plan accordingly
After meetings with the customer and as well with the technical team, we should be able to identify if we need third parties.
Additionaly, we will have some internal dependencies as well as from the customer. We might have resourcing to take into account that needs special planning. Also, tasks will have to be planned as core, without which the app or features will not truly be stable or whole and over which we are building the rest. There is also data or integrations we need to wait for .
All these are dependencies, and need to be taken into account when planning.
Also, a risk assesment has to be done on them, with a mitigation plan and clarified for the customer.
If deciding on a minimum viable product, think of reusability
For faster time to market, we have to think of a minimum viable product and also explain to our customer why is that.
And I will not go into detail as to why having consistency and reusability in mind is important when building a product or part of it, but it will help for further phases into the project or product.
Also, it will help us to not have to explain to the customer what is the value they were getting in the initial phases if they have to redo part of it to include further features, and build a good trusting relationship with them.
Prepare yourself to be flexible
Another thing that I see as being a natural ability we should have as project managers, is being flexible. We have to constantly adapt to customer and team needs, project needs, etc., so when building something we have to also be able to readjust assumptions, priorities and dependencies. Technology can bring new things, teams and stakeholders cand and might change and requirements will be updated. If we are not open to accept this, we will have a hard time.
Read Also:
You might be interested to read more about why an MVP might be a good option for your product and some steps to follow – check out my post on MVP – What, Why and How here
Leave me a note:
If you have some ideas or want to share your thoughts on remote working and how to handle it, please drop a few lines on
say-hello@projectmanagementlifopedia.com
silvana comanici-stoianov 