Welcome to my Project Management Best Worst Practices blog!
Nobody kicks off a project with the intention of developing a product that is delivered considerably over budget and substantially late, but let’s face it — we all know that it can happen all too easily, especially with inexperienced project managers at the helm. In this blog, I’ll be posting tips about things I’ve learned in my 20+ years of product development (often the hard way) about what to look out for when managing a project, as they are usually major red flags of a product that won’t be delivered on time, within budget or within the original scope.
Worst Practices Tip #1:
Starting the whole team working on a project that all stakeholders have a vague idea of what the end product will be.
If all stakeholders have just a high-level concept of the end product, it’s pretty likely that each of them will have a different vision in mind. And it’s highly likely that most of those visions will be different than the vision in the development team’s minds. Before one line of code is written or one final art asset is meticulously rendered, all stakeholders must have a clear understanding of the end product, so that everyone is on the same page.
If your team has worked with the stakeholders on a previous product (especially if that product shares many of the same features as the new one), conveying what the end product will be shouldn’t be a major challenge. This task is more difficult with new stakeholders, especially when the stakeholders are from other industries or disciplines. The more that you can use previsualization tools (like wireframes or rough storyboards), the easier it will be to get everyone on the same page. Keep in mind that it can be easier to get “buy in” with rough visuals than with something more refined, as it can be confusing for some stakeholders to know what to focus on with partially complete graphics and what should be ignored (to avoid questions like, “Is that really what that character is going to look like?”). Also, don’t waste the stakeholders’ time with too many of the “under the hood” details at this point, since simply uttering a phrase like “optimized lossless data compression algorithm” can easily make some of your audience’s eyes begin to glaze over. As much as possible, don’t stray from what the end-user’s experience will be, as stakeholders (rightly so) are generally hyper-focused on the customer perspective.
It’s highly likely that the stakeholders will have feedback when initially presented with the product concept, all of which should at least be considered. It’s also likely that some of the feedback received will impact the project’s budget, schedule or scope so those implications need to be clearly communicated and discussed. Even though this phase can sometimes be frustrating or take longer than expected, an important thing to keep in mind is that stakeholder feedback about a product’s definition is easiest to incorporate during this stage of development. That’s why it’s critically important that everyone is exactly on the same page and no stakeholders have merely a vague concept of the product before your team moves on to the production phase.
worstpracticesblog 