Unveiling the Project Soul: Navigating the Journey of "Why"
Dear Twenty-Something-Me,
This was a question I rarely asked when running projects - why are we doing this project? Does the team understand and buy into the “why” and the value the project brings? If you or your teams aren’t convinced of this answer, then your first step is to talk to the Product Manager.
The “why” is something Product owns. The “why” isn’t just about the deliverable, but also the core benefit of the project. If the "why" is well defined, then I have found that executing and delivering the project keeps team members energized and gives them something to feel proud to work on!
This article will provide project managers pointers for getting to the “why” and core benefit, and provide reasons why it’s important for planning and risk mitigation:
- Who needs to answer the “why”?
- Preliminary questions for getting to the “why”
- Understanding the origins of the project
- A technique for getting to the project’s core benefit
- The Importance of “Why”
Who Needs to Answer the "Why"?
The following roles should answer the main question and any other questions about the “why”?:
- Executive (Exec) Sponsor: Understands the portfolio and business implications of doing this project and the risks of not doing it
- Product Manager: Owns the “why” and should have research and data to justify the project to outline the core benefit
Preliminary Questions for Getting to the “Why”
Here are some questions to consider when speaking to the Product Manager or while reading their documentation around about the “why”:
- What problem are you trying to solve?
- Who else has tried to solve the problem?
- Who are the competitors in this space?
- What is this company bringing to the table that others aren’t - what is the value-add?
- Are there any partnerships or vendors that can be leveraged to solve this problem, even partially?
- What is the “customer ask”?
- Has the customer been identified? This could entail a sector, a segment of an industry/segment facing a particular problem, specific customers, etc.
- Is this something other customers can use or is this a one-off for a customer?
- Why is the customer asking for this?
- Why would the customer need this solution?
- Is it something the company is delivering poorly?
- What exactly is the context of the ask?
- Is this related to a particular product?
- Is there data to show these issues?
- Has the customer been identified? This could entail a sector, a segment of an industry/segment facing a particular problem, specific customers, etc.
- How does this project link back to the company vision, mission, and goals for the quarter or year?
These questions might be called out in a market research document or captured through the company’s intake process (if either one of these exists).
Understanding the Origins of the Project
As a project manager, stopping at the “why” can be sufficient, but knowing the origins of the project also helps frame the “why” more holistically, and can sometimes tease out major red flags (see my example below!). Here are a few questions to ask:
- Is this project driven by a Product team supported by market research and included as part of the portfolio of projects that need to be executed?
- Is this project needed internally to improve productivity or performance?
- Is this project a “customer ask”? If so, how many customers are asking and how much revenue will it bring in for the existing customers and potential new customers? Alternatively, how much revenue is at risk if a customer churns because we don’t deliver this project?
- Is this a pet project for an executive or something someone thought was "cool" based on a demo, prototype, PoC?
Knowing this will help project managers understand how this project came about, and provide more context when looking at the "so what" or "why" approach to see if this project should even continue. It also helps the project manager understand their circle of influence and who they need to approach if scope, budget, or timing for release changes.
Example of a project gone sideways for not asking these hard questions
I was once put on a project that was about to launch. I had just started with the company so I had no context about its origins, but it was supported by an Exec Sponsor and Product Management. I was taking over the project from another project manager so I quickly got into tactical mode because the launch was under a month away! When I spoke to the Product Manager, there was a business case around it, but I didn’t take the time to dig deeper and ask more questions (even at a high level), and I really should have done that. Right before we were going to launch, the Exec Sponsor mentioned in passing that this project was based on a Hackathon project that was completed in December, and they were going to launch next week ( 2 months from the Hackathon). My jaw dropped because I knew it was very unlikely we could take something that was a prototype and turn it into a polished NEW PRODUCT and SELL it to EXTERNAL customers while maintaining quality! It was something the Exec described as “cool technology” on which the product management team built a retroactive business case/product/marketing material. We ended up spending a lot of time post-launch working on tech debt, but it wasn’t enough. This product ultimately had to be sunsetted because of the tremendous amount of tech debt it incurred out of the gate and did not add value to the product portfolio.
A Technique to Get to the Project’s Core Benefit
Once some of these preliminary questions have been answered (and there will be more as answers are uncovered), try the “5-Why” or “So What” approach of digging even deeper - this will help bring out the core needs, benefits, and even dependencies and risks of the project even before starting! I liked this article by Eddie Shleyner about the “So What” approach for a product. He provides a nice example.
An Example of the “So What” Approach
Here’s an example of doing the “so-what” approach that helped me understand the direction of the company, and gave me perspective and appreciation for the grind we were about to start.
There was a project to build a new data pipeline from the ground up. This wasn't a product we were selling, but it would become the backbone of all the products we sold and would sell in the future. The teams have been working on maintaining and slowly updating the existing data pipeline for years on a two-person team without significant progress. When the technical executive management changed, they made a huge decision to go into maintenance mode for all products and focus new development on the new data pipeline. It made sense to do, but why did we need this now? Customers were already asking us for so many features and products so this move would severely impact sales. The breakdown is linked in this table.
So yes, we spent several months building something solid. All the while keeping a focus on the end goal and why we were doing this instead of introducing new products to sell. It was very clear that we were sacrificing the near-term goals for the long-term goals.
It was so energizing to hear this message! We prioritized what we needed to do well and stopped adding tech debt by making new features and products while going through this change. I knew we were building something for the next ten years to come! This project will set in motion all future products and will be pivotal to the success of the company. Products and features can be integrated more efficiently and comprehensively, helping sell more products faster to ultimately allow us to provide more value-add to the customer.
Having said that, the downstream risks were plenty! It required a lot of coordination with leadership teams to kick off many investigations and their eventual projects with appropriate resources. In this particular case, these downstream risks and dependencies were not something a single project manager could do in isolation through their risk register. This kind of project greatly impacts Product, Development, and any customer-facing teams and is something leadership would need to help coordinate with adding appropriate resources (people, budget, tooling, etc). It meant that all products would need to re-visit their data integration and the internal customer dashboard would need to be re-written. Many projects had to be kicked off because of this change.
The Importance of "Why"
The value of answering the “why” is part of setting up the project and the team for success. It allows the team to make informed decisions about the project. It helps the project manager understand the upcoming risks and work with the team around mitigation tactics, which in turn will help with planning. The project manager also benefits from knowing the origins as it can provide insight into the circle of influence when reviewing changes to scope, budget, or release schedule. The “why” and "origins" should be shared with the team and published (perhaps a link on a project landing page).
A Harvard Business Review around “purpose”, mentions that a company that is driven by “purpose” is 2.5 times better at driving innovation and transformation. I want to note that the “purpose” and the “why” are slightly different, but closely connected. The "why" focuses on specific reasons behind product decisions (e.g. releasing Feature X ahead of Feature Y because it will help sell the product to Customers A, B, and C who have been on the fence for signing a contract). Whereas the “purpose” encompasses the broader mission and impact of the product for the business (e.g. releasing Product Alpha with Features X, Y, and Z, will enable growth in a vertical that the company has been targeting to enter). The “why” should fit into the “purpose” of the company. Therefore, knowing the “why” and the “purpose” and how they fit together should help with driving innovation and transformation as well.
At this point, if there are concerns with the answers to the “why”, then it should be reviewed with the Exec Sponsor, after which there should be a discussion with the business to make sure the project still makes sense and the scope adjusted to maximize value for the company. So, please, please, please, no matter what stage the project is in, when you join a project ASK the hard questions.
Good luck, 20-Something-Me! This is a hard set of questions to answer! It might feel like you’re stepping on toes, so be tactful and mindful not to point any fingers, but work as a team for the project and the company's benefit. Sometimes you’re not always going to like the answers, but if the people who are making a lot more money than you decide to still move forward, then commit and do the best you can!
Trust yourself and be kind to yourself,
Your Future Self
Is there something else that you think should be included when looking at the "why"? Or something you think can be done differently? Please provide a comment with an example so that we can all benefit.
Member discussion