Today’s blog is centered around helping you achieve your goals by overcoming management obstacles the right way. You can expect to learn:
- The significance of precise requirement gathering
- Setting realistic expectations
- Navigating client needs vs wants
- Responsibilities and ownership
How to gather requirements
The first step in any large-scale project is understanding client pain points (and wants) and ensuring teams comprehend the requirements as a whole. The ability to provide quality deliverables starts with your ability to properly harvest the right information to actually understand what those deliverables might be.
Therefore, it’s crucial to assess, analyze, and revisit stakeholders’ needs so the person of contact (POC) can communicate requests to the technical teams with full confidence. Both your team and stakeholders must have a clear, concise and shared understanding of expectations.
Over-communicate and repeat when necessary
Sometimes repetition is helpful to ensure everyone is on the same page. Examine all communications to ensure every issue, request, and expectation is substantiated with evidence. Re-ask if anything is unclear.
It’s imperative to make sure all agreements are written/recorded, signed, and filed. This helps mitigate the risk of misinterpretation and potential document deviations along the way for both your team and the client. This should include the decisions that led to an agreed upon requirement and also those that led to the exclusion of specific requirements in some cases. This step is usually best performed by a Business Analyst or Project Manager.
Insider info: Content Bloom always conducts an in-depth business analysis (BA) when onboarding a new project to ensure all requirements are documented. It helps us a gain greater knowledge and a more comprehensive scope of the overall project, allowing us the opportunity to communicate deliverables and solutions to teams on a much deeper level.
Investigate
Remember that game telephone? Too many people offering information to the wrong points of contact can cause confusion. Ensure you’re getting your facts from the appropriate stakeholders. Having a POC on both the team and client side is key because it’s easy for communications to get jumbled when too many people stand between point A and point B.
A real life example
A client’s IT team reached out for help because they needed our expertise in implementing an upgrade (or so we thought). However, after a full BA, we discovered that the upgrade was expected to solve all of the technical issues marketing and content teams were facing. This highlighted some unrealistic expectations because solely performing an upgrade to the Content Management System (CMS) would not have solved the rest of their noted content management concerns.
After recognizing this as a risk, we dove deeper and learned marketing was spearheading these updates (not IT) and our client’s actual needs differed significantly from what was initially communicated.
In a scenario such as this, without the proper investigation, communication, and strategy set in place, stakeholders would have been confused as to why the CMS update didn’t solve their content issues, resources would have been wasted, and everyone would feel dissatisfied.
This is why it’s essential to not only ask the right questions, but also corroborate the answers to ensure everyone is on the same page when it comes to requests and expected outcomes.
This brings us to expectation management.
Expectations vs reality.
With every scenario you must manage expectations from not only a technical perspective, but a wider, all-encompassing perspective. This is achieved by working with a broad range of teams to define and understand the whole scope of the project on a larger internal scale.
Be Specific
As in our earlier example, it was critical to ask the right questions to pinpoint specific needs. Knowing the right questions is something that a more experienced partner will bring to your table. There’s no basic formula here but incomplete answers, answers that don’t fully answer your question, or answers that actually lead on to other questions can lead to confusion. Here are some starting points:
- Is this an upgrade?
- Why do you feel the need to upgrade your platform?
- Is there an expected outcome other than new features?
- What are your teams’ specific needs?
- What are your teams’ main blockers?
- What’s your anticipated timeframe?
A clear understanding (from both sides) of realistic timeframes, budget, deliverables is a top priority.
Sometimes a project is as simple as an upgrade, but other times the original request turns into something much more complicated, like a complete re-architecture on the content model. If the latter is the case, timeframes, budgets, and onboarding would need to be reassessed, goals updated, and tools revisited.
You never want to over-promise or underdeliver, being transparent and realistic is the only way to mitigate potential risks and the only way to deliver a successful solution.
Work with your client
It’s important to recognize the difference between understanding your client’s needs vs. their wants. Why is this important? If the client isn’t very technical or they’re simply following the orders of a non-technical team, the project scope and business-valuable requirements can become hidden in the list of “wants”.
There is also the possibility that what your client wants does not align with company goals and may even be contradictory to their longer-term business needs. That’s why it’s important to not only look at the current operational set-up but to also talk strategically and ensure ideas have been thoroughly examined from all angles. Our job is to ensure these technical desires do not compromise the client’s overall business goals.
In our experience, having a team that knows how to navigate the chaos that can ensue when you combine business goals, technologies, strategy, and management makes all the difference.
What’s the pecking order?
There are often multiple stakeholders responsible for different aspects of delivery and it’s your job to help determine the respective priority of the various deliveries. Sometimes the highest priority items won’t be the first deliverables on the list due to various business or technical dependencies.
Sometimes deliverables will compete for time or attention but not have an apparent difference in priority. In these instances, it’s vital to know who is at the top of the chain of command; managing stakeholders means communicating exactly what the project entails.
This sometimes means informing stakeholders that their priority 1 cannot be worked on until 5, 6, 7 are complete, irrespective of how passionate they may be about their own independent requirements. Just telling someone that they’ll need to “wait to see their change” may not elicit a great response, so be clear and concise in your communications but also be reasonable and informative.
Are you still feeling uneasy about taking on a new project in our current economy? Don’t be. Content Bloom is offering a free first consultation to CMOs, CTOs, and Project Managers looking for insights on how managed services and technical implementations can improve business in 2021. Reach out.
