Golden Quadrangle – A Choice between Scope, Quality, Cost and Time – Choosing the lesser evil

It is always known, observed, and seen that Project Managers use tradeoffs to provide decision-makers with data on the impact of a change on scope, time, cost, quality and risks (Though I mention this, I have never seen a proper and adequate level of impact analysis to the level as needed and required), then the sponsor understands the full impact whenever they have a variance or a change request.

Tradeoffs help maintain the project’s feasibility.

Check this fictional conversation:

Situation – Fixed Price, Fixed Scope, Quality Parameters have been agreed and Cost is Pre-agreed, The SoW is signed off. Contracts are in place. Planning is done and dusted, now the project is in execution phase.

And Bingo … we have an interesting request from the customer to the sponsor to change the dates of delivery and so the conversation happens somewhat like this:

The sponsor says to the project manager, “I want to move up the finish date from June 30 to May 30. Make it happen.” The sponsor starts to leave the meeting.

The project manager says, “Yes, I can shorten the duration of the project by four weeks. Your assistant told me about that, and I modeled it. To cut a month off the duration, I will need to have two additional developers and a tester for the month of April and the budget will increase by $10,000 for extra resources.”

A tradeoff has two sides. First, there’s the positive side where the PM shortens the duration of the project. Second, there’s the negative side where the project manager says they need an added budget for two additional engineers for the month and additional consultants.

The sponsor says,” No all I want is to cut the duration. No additional people or money.”

The PM says, “If I told you I could do that it would be lie. To shorten the date there will be other changes. It is not possible without consequences.”

The sponsor responds, “A good PM would be able to do whatever I want!”

Then the project manager replies, “But it would be a lie.”

Who wins this conversation / argument / decision making process, well it may seem that that the Sponsor would force the Project manager to agree to his / her ideas and thought process, but ultimately project drags on time and cost, has poor quality (a lot of defects, un-tested elements), team members have burnt out, the morale is low and customer is unhappy writing stinker of emails, there is a all-round loss and credibility issue, but who cares.

Did the sponsor review the impact of the new need / requirement where in the timelines / duration has been reduced?

Requirements for Trade offs

Tradeoffs are part of the toolset good project managers use. They must build the project plan with quantified measurable outcomes for every delivery. And the schedule must have work estimates and accurate precedence relationships. Then model every change with its compensating tradeoffs.

When project sponsors want to make a change, successful project managers never say, “Oh no, we can’t add that to the project.” What they say is, “Certainly I can add that to the project, but I will need three more people full time.” Other negative sides of the tradeoff could be, “We will have to increase the budget by $ XXX” or “We’ll have to reduce the savings in our scope by $ XXX.”

This is the language of tradeoffs. The project manager is not saying no. Instead, they are telling the sponsor or stakeholder what it will “cost” to bring about the change they want. Tradeoffs maintain the feasibility of the project. Merely shortening the duration does not.

There are no easy solutions and no easy decisions that one could make … Impact Analysis and Cost of Delay as a concept should be utilized for proper decision making.

Remember in any project, on one side we have the leadership / sponsors and others who at times have un-reasonable demands and the other end of the spectrum we have project manager who is trying to make the ends meet … Due to job constraints and lack of their ability to standup, the project manager looses the game and finally leadership and sponsors lose money, get poor quality and loss of face to the customers.

We have always tried to be penny-wise pound foolish

With all said and done, changes would occur and would be required to be managed. How should a tradeoff occur? What parameters should the Project manager be concerned about?

Juggling the 4 corners of the Project (Standing on 4 Pillars)

Any project would have to learn to live with these 4 corners of the game:

• Project scope (including quality of deliverables)
• Time / Duration
• Risk
• Cost (human resources and materials).

Which is more important? Given an option to make a choice, Let see a few permutation / combination to make a judgement call.

Let us say Scope is Changing, it is increasing … Then

Scope Change: Impact would be on: Quality, Cost, Time (atleast on one of them, but if you really think, it will impact all of them)

Where do we prioritize the approach, what should be the order of our decision making and relevant / related impact, Should it?                               

Order of Impact / Decision	Order of Impact / Decision	Order of Impact / Decision
Cost	Quality	Time
Time	Cost	Cost
Quality	Time	Quality

It is not an easy decision, but if quality is a thought, then as per me, it is a bad / poor idea. Spend more on Cost and try to minimize the impact on Quality and Time

The project is like a tube of toothpaste. When management / sponsors squeezes on a project’s duration corner by cutting the due date by a month, the toothpaste compensates by oozing out from one of the other corners. When the sponsor squeezes the duration, it will deliver less scope, cost more, or have a higher risk of failure and this is the kind of impact analysis that is required to be performed by the project and related stakeholders.

Changes in one parameter would always impact at least one other corner. That fact exists whether people recognize it or not. It’s not realistic to assume that making arbitrary changes to one corner of the project, like the duration, can happen without any compensating effects through the rest of the project.

Interestingly, the majority of the leadership and sponsors fail to recognize this impact. Because in most projects only one, or at most two, of these corners is measurable. The completion date is always measurable and is often rock solid. In some situations, the project budget is also measurable. But most internal projects have no other measurable dimensions. Even with the two measured dimensions of duration and budget, the business value of the project (the scope) and the risk of not delivering that scope on time are usually unmeasurable. So executives continue to make arbitrary changes to the duration and the budget and think that it will have no impact on the project’s scope, quality or risk.

What concerns me is that most of the leadership have no clue on this front, each of these leadership person must have risen through the ranks and would have faced these similar challenges in their project management days and now they behave very differently. Does change in position also impact the way a correct process should be adopted?

Is this science so difficult that we do not understand elements?

I recommend performing “What If” Analysis, where one can watch the impact of moving one parameter (or as we say one pillar) over others. This requires building some models (but once you do it, will serve the organization for its life), then performing different permutation and combinations can give all type of results, choose the lesser evil.

When doing such analysis, keep emotions out of the window and work on real and hard facts.

Do let me know your experiences on this front, would be an great discussion over coffee !!!

Scrum Master = People Oriented Master

One of the main task for any Scrum Master is to manage and motivate the development team (do not forget the Product Owner) to deliver the best-in-class output with outcome to the respective end-users / stakeholders. Pure Agile / Scrum processes will not achieve this, A Scrum Master above all else should be a people person.

During the life of the product development, Scrum Master would enable / facilitate creating a range of tangible deliverables that are critical to the meeting of DoD and release to the production. These would include Impediment board, risks, teaming agreement, cadence of sprint and so on… The funny part of the story is that when the product is delivered all the tangible outputs that we are speaking about would be of no use (atleast to the end-user community). They have little or no value outside the life of the product.

It is important for us to understand that Scrum is all about people, who help to create beautiful and meaningful outputs that serve the needs of the stakeholders and market in general.

The main task for the Scrum Master is to ensure that the development team can deliver and all blockages that occur in the journey of theirs are removed or assisted to be removed.

Over next few paragraphs, we shall de-mystify the needs and requirements on what and how a Scrum Master should enact the approach.

Step # 1 – Get the basics right – Right People, Right Skills, Right Tasks.

As a Scrum Master, help, guide and assist / facilitate the development team to get the right skilled people -with adequate dose of attitude and aptitude. Do not focus on technical skills, focus on learnability, ability to survive in a tough environment, how to respect, being open, have the right level of commitment to the team and others.

There would always be some gap between your needs / wants vs. what talent is available. Remember a perfect match may not be available, try to manage this as a risk and work towards mitigating the same. Try to always get a balanced set of capabilities and skills, do not fall in the trap of choosing all the folks that favor you or you like. Infact look for people who can work with others and create magic for your customers.

Also find a balance between internal and external resources, several times you may be forced by the Leadership to take an internal person (in order to save on cost) but evaluate the person as you would when you take any external resource and ensure it fits in your culture band that you are building in your team.

Step # 2 – Go for Quality rather than Quantity.

More resources may not always be the right approach, but the right resources is what matters. Life and experiences have always suggested that a small set of motivated people have delivered far more than a much larger group of able people. Be the master negotiator with the leadership or the resource allocating person to get the best talent for your team, you may have to act as a salesman to get the right quality in your team (Scrum does not talk about this … but it is critical)

Step # 3 – Clear Roles and Responsibilities.

For any team and individual – we all look for clarity of our roles and expectations, how shall we be judged. Yes, there are no defined / allocated roles in Scrum, but it does not hurt to have pseudo approaches for the initial few sprints and then educate the team to self-allocate, self-define how they want to work out. Scrum Master is like parenting job, initially we would be required to do babysitting, but the as team grows, becomes more mature , our role should be limited to guidance and coaching.

Step # 4 – Building the team

Do not take for granted that Team is automatically built – You need to invest your sweat equity into it.

There is no right or wrong way to build a team, different cultures, different set of people will bond in different lengths of time. To build the team with right values, try these elements:

• Ensure roles are clearly understood
• Ensure communication channels are open between you and the team and amongst the team
• Bring people together (More physically)
• Give people time to know each other
• Have the Product Owner address the team on the needs, vision, big picture, roadmap of the product in focus

Step # 5 – Focus on personal development of team members

It may not be the core objective of Scrum Master, but not focusing on the same would have adverse impact.

Face this task much earlier in the life cycle, ideally when people first get involved in the team, As a part of their initial induction have an understanding of their career needs and wants. The areas where they want to grow and contribute. If their expectations are out of line or un-reasonable, then put it straight on the record.

Help the Product Owner agree to have about 4-6 Hrs / Sprint (Assuming 2 weeks of Sprint cycle) to get it invested in growth, learning of new tools, more on the product development, team building, exploration of new ideas (like using Gen AI to help in the development) and so on … this is a bit of selling exercise with the PO and team (also!)

However, make sure that the training / workshops or getting people involved in specific things do not derail the product development, it should not deviate from the core objective with which the team was formed.

Step # 6 – Be aware of team dynamics and politics

When people work together, they develop their own style of communication. Working together, as a Scrum Master your ability to understand the team dynamics is going to become more critical and critical.

Note: There is no right or wrong team working style or responding to team dynamics. Team dynamics will never remain static, it changes over a period – and when the team matures or new team members join, old ones move on, this can help you rebalance the approach for the team.

Implement PI (Predictive Index Assessment) for everyone on your team. Identify their personalities and ensure you and others in the team understand how to deal with a given personality. This is no rocket science, but not knowing how to deal with a Collaborative vs. Strategists can cause unwarranted losses and damage to the morale of the team and thereby to the product.

Encourage openness and honesty – when these elements are in place, then the team would have few barriers to open communications.

Remember to lead by example if you do not want politics in the team, then do not politic yourself. You want to be trusted by the team.

Final note on this one – Team is more important than any individual, In Agile it is the team that would deliver and not an individual.

Step # 7 – Managing Part time resources 

At times, you may not get a fully dedicated person to work on your product development. You would have to work with Shared resources, when such a situation arises, ensure:

• To get fixed and measurable time from shared folks
• Make sure you have sufficient skills and talent and working hands, remember it is not the number of people in your team, but it is the amount time that these folks are ready to devote to you.
• Recommend your team to build a little slack and inefficiency in the approach (this acts like a risk mitigation strategy)
• Your approach to managing the time utilization (not saying to act like a project manager- but watch the game) would be critical to the success of the delivery

Step # 8 – Working with the Wider Organization 

Remember your team, the product’s existence is never in isolation. There is always a requirement with some other function, department to get your product out of door, it could be the marketing or the sales team or the travel team (to book your tickets, hotels) or some other platform team whose output would be critical for integration and working of your product.

There is always to a need to manage relationships with the wider organization, and it would vary depending on context and content of the product as developed, Therefore as Scrum Master is it important to guide and assist the team to manage these relationship internally in the system.

Providing adequate and timely notice to dependency would help them plan their side of the work and provide sufficient time allocation for your work.

Step # 9 – Have a sense of humor  

The ability to generate and enjoy humor is an extremely positive trait for a Scrum Master. Developing products / projects can at times be quite stressful – the ability to laugh and crack jokes (not on any individual) would help the team manage the stress.

If you are not natural at this … do not worry, just smile a lot. People love to see a smiling face, do not underestimate the power of a simple smile. A well-placed smile of yours can completely change the dynamics of the conversation, can lift an individual from a negative stance to a positive frame of mind.

These are a few ideas that has potentially given me the required results and mind you – it has always worked.

Try it – and then Inspect and Adapt.

Work Life Balance – Is it a Myth or a HR Jargon or Practiced in reality?

Work-life balance in the IT world / industry can be a complex and a difficult issue, as the nature of the work often involves long hours, tight deadlines, and high-pressure situations. While achieving work-life balance in the IT industry can be challenging, it is not impossible, work-life balance is an essential concept, it can sometimes be challenging to implement effectively in real-life organizational setting, but many organizations within the industry are actively working to create a more balanced environment.

I remember during the pandemic, when the entire (I would say about 98% of us) were working from home, It was very worrying for me, if someone called me and I was not in front of my laptop (could be a washroom break, or gone to answer the doorbell), it was assumed that I am not working, Where as when you are in office and people see you once and then you are not on the seat / or your place, it is acceptable – I can spend a whole 1 hr. chatting with someone in cafeteria and that would be considered just fine. My issues are a little different as people behave differently as the policies and the leadership approaches are erratic.

Why do we have challenges in maintaining the Work-Life Balances at our workplace, with my decent experiences of working across the globe and for different types of organizations, I have got some interesting thoughts here – which may resonate with you, Do check them:

Inadequate Project Management and Planning: Poor project management and planning can play a significant role in work-life balance. Unclear communication, unrealistic deadlines, and no proper resource allocation – all these aid to excessive workloads and the need for constant overtime. Prioritization and efficient time management are crucial in maintaining a healthy work-life balance. The 1^st principle for good work and time management – here goes for a toss.

Lack of Boundaries: In some work environments, there is a blurring of boundaries between work and personal life. With advancements in technology, employees may find it difficult to disconnect from work, as they are constantly connected to their devices and expected to be available outside of regular working hours. This lack of boundaries can erode work-life balance and lead to a sense of being “always available.”

Limited Support Systems: Despite having work-life balance policies in many companies, organizations may not provide the necessary support systems to help employees achieve balance. For example, inadequate childcare support or limited access to wellness programs can make it challenging for employees to effectively manage their personal commitments alongside their work responsibilities.

Cultural Expectations and Peer Pressure: In certain workplace cultures, there can be unwritten expectations that employees need to constantly be available and put work above everything else. Peer pressure and cultural norms within the organization may discourage employees from prioritizing their personal lives or taking time off, even when work-life balance policies are theoretically are existing. It is just a hoax to have such policies in the 1^st place – Not sure how employee (including me) falls in such trap.

Long Working Hours Culture: A variant of the above mentioned point, many industries and organizations have a prevalent culture of long working hours, where employees are expected to work well beyond their designated hours. This culture often undermines work-life balance, leading to increased stress, burnout, and a lack of time for personal commitments or leisure activities. Organizational culture and expectations can make it difficult for employees to truly achieve balance as needed in life.

Demand for 24/7 Operations: The IT industry often operates in a 24/7 environment, particularly in areas such as software development, cybersecurity, and IT support (this is the nature of business). As we go global, the customer wants solutions and resolutions to their challenges and problems during their day-time – which could be off-hours for people working in different time zone.  This can lead to employees being on call or working irregular hours, which can impact work-life balance. However, organizations can implement measures such as shift rotations, adequate staffing, and clear expectations around availability to help mitigate the negative effects. (I would state a few organizations have performed Shift approaches, extra cash, transport facilities and others to help their employees work effectively)

Final Approach:

It is important to note that while these elements as stated exist, there are also organizations that prioritize work-life balance and successfully implement policies and practices that support their employees’ well-being. However, the challenges mentioned above highlight the need for organizations to go beyond policies and actively create a culture and environment that values work-life balance, promotes flexibility, and supports employees in achieving harmony between their personal and professional lives.

While work-life balance in the IT industry may present unique challenges, organizations are increasingly recognizing its importance and taking steps to address it. By implementing policies and practices that support flexibility, well-being, and effective project management, the industry can create an environment that enables employees to achieve a healthier work-life balance. However, it is important to note that the extent to which work-life balance is achievable can vary between organizations within the industry, and it may require individual efforts as well.

Business Analyst to Product Owner – A journey to unfold or it is a mismatch of roles and responsibilities.

In today’s rapidly evolving business landscape with many disruptions, new technology changes, digitization’s, certifications, Customers becoming more demanding and , agility has become paramount for organizations seeking success.

As Agile frameworks continue to gain momentum, the role of a Business Analyst (BA) is also transforming. Many Business Analyst aspire to take on more strategic responsibilities and broaden their impact within the organization, many of them would like to be associated with Agile teams, but business analyst is not even a role as recognized by Agile world.

One such transition that often comes to mind is moving from a Business Analyst to a Product Owner (it seems a natural movement). Is it so simple to migrate to the new role in new ways of working?, If you are as confused as I was a few days ago, then continue to read and explore the thoughts that I have jotted down here.

In this blog, we will explore how a Business Analyst can upgrade / migrate to become a Product Owner in an Agile environment.

Before we delve into the transition process, it is essential to understand the key distinctions between a Business Analyst and a Product Owner. While both roles involve collaborating with stakeholders, their focus and scope vary.

A Business Analyst primarily acts as a bridge between business stakeholders and development teams. They gather and analyze requirements, identify business needs, and ensure alignment between stakeholders and the project team. BAs are skilled in eliciting, documenting, and managing requirements throughout the project lifecycle.

On the other hand, a Product Owner is a critical role within Agile frameworks such as Scrum. They represent the voice of the customer and are responsible for maximizing the value delivered by the team. Product Owners prioritize the backlog, work with the team and the stakeholders (including but not limited to End users) to define user stories, and ensure the team understands the product vision.

To transition from a Business Analyst to a Product Owner, it’s important to identify and address the skill gaps. While BAs possess valuable skills, they need to acquire additional competencies related to product management and Agile ways of working.

1. Product Management: Business Analyst should develop a deep understanding of product strategy, market analysis, user research, and product lifecycle management. They need to think strategically, define product vision, and make informed decisions to maximize product value. You need to master more tricks in the game to learn how to negotiate, prioritize and formulate the product backlog.
2. Agile Frameworks: BAs should familiarize themselves with Agile principles and frameworks such as Scrum, Kanban, and others. They must understand the iterative nature of Agile, embrace adaptive planning, and learn to collaborate effectively within cross-functional teams and not worry about ever evolving requirements, but learn how to manage the stakeholders, keep expectation management in scope and manage the risk of not meeting the commitments.
3. Stakeholder Management: As a Product Owner, relationship management becomes vital. Developing skills in stakeholder engagement, negotiation, and conflict resolution will enable smooth communication and alignment with stakeholders throughout the product development journey. Product owner needs to be decision maker. Understand the different stances of the product owner and know when to en-act which stand with stakeholders at the different durations and time intervals with the stakeholders / customers.

To upgrade to a Product Owner, Business Analysts should actively seek opportunities to acquire the knowledge and skills necessary for the role. Here are a few practical steps to consider:

1. Self-Study: Read books, articles, and blogs on Agile frameworks, product management, and the role of a Product Owner. Online platforms and communities offer a wealth of resources, webinars, and podcasts that can aid in self-learning, Participate in webinars, meetups, conferences, online sessions, review and listen to podcast – there is tons of data and information available in the industry – know the right source and the right place to acquire the available information. Again, a word of caution – do not read everything – follow some known Guru’s and experts from the market to get the right guidance.
2. Collaboration and Mentorship: Engage with experienced Product Owners, Agile practitioners, and industry professionals. Seek opportunities to shadow and collaborate with them, learning from their experiences and gaining practical insights. Try and seek a 1:1 session, exchange your queries and doubts, create situations and scenarios to gain insights into the thinking pattern of these experts – a lot of data to consume, filter the information for the right reasons.
3. On-the-Job Experience: Look for opportunities to take on Product Owner responsibilities within your current organization or in side projects. Start by actively participating in backlog refinement sessions, sprint planning, and user story development, at times participate (with permission) to only observe and see the whole flow getting worked out. – You may not be associated with the project, but by participating, observing one would gain tremendous thought process, which again should be harnessed by self-study and mentoring approaches
4. Training and Certification: Consider attending workshops, seminars, and certification programs that focus on Agile frameworks and product management. Certifications such as Certified Scrum Product Owner (CSPO) or Professional Scrum Product Owner (PSPO) can help validate your knowledge and enhance your marketability. Test your skills and knowledge via external validations, which can be easily done with different certifications from the industry, when you choose a training or workshop, evaluate the trainer, seek past feedback and references, do not evaluate over the cost.

Final element of this game should be to practice what we have gained, learnt or mastered, Transitioning to a Product Owner role requires effectively showcasing the skills and experiences gained as a Business Analyst. Highlighting these transferable skills will help demonstrate your readiness for the new role:

1. Requirement Analysis: As a BA, you have honed your ability to understand complex business processes and translate them into functional requirements. This analytical and problem-solving skill set is highly valuable for prioritizing features and defining user stories, Learn techniques such as Cost of Delay (CoD), MoSCoW, Force Field Analysis, Buy a Feature approach – these techniques would enable better management of the product backlog and meeting the needs and requirements of your customer.
2. Domain Knowledge: BAs often gain industry-specific knowledge through their projects. This domain expertise can be invaluable in understanding user needs, identifying market trends, and making informed product decisions. Understand the working of the industry, if the industry as you are associated with, is regulated, then learn about the issues, impact of decisions by the statutorily bodies on your product and services and how the requirements would evolve in the given situation and context.
3. Stakeholder Collaboration: BAs frequently interact with stakeholders, ensuring their needs are met throughout the project lifecycle. This experience in gathering and managing requirements and facilitating communication can be leveraged in the Product Owner role, this is no different for the Product Owner role, but learn to play the different stances of the product owner at different time to create the necessary impact on the product, its evolution.
4. Communication and Documentation: Business Analysts excel at clear and concise communication, as well as documenting requirements and user stories. These skills translate seamlessly into effective communication with development teams, stakeholders, and user groups as a Product Owner, Learn to communicate with minimum documentation, embrace the Agile manifesto and its principles – Interact with teams and stakeholders, have informal coffee chats. Get engaged with the people whom you work with or people who work with you.

Before you take the final call, be aware of these Anti Patterns when you move from Business Analyst role to a Product Owner one

1. Difficulty in prioritization: BAs often deal with multiple projects and requirements simultaneously, which can lead to difficulties in prioritizing features effectively. As a Product Owner, having a clear understanding of the product vision & strategy and the ability to prioritize based on user value, business impact, and market needs is crucial. Failure to prioritize effectively may result in a product that lacks focus or fails to deliver the most important features first. Remember Product Owner is a decision making role.
2. Lack of ownership and accountability: BAs typically operate within a structured framework and may not be accustomed to taking full ownership and accountability for the product’s success. As a PO, it is essential to take responsibility for the product, make tough decisions, and drive its overall direction. Without a strong sense of ownership, the product may suffer from indecisiveness or lack of direction. Remember in Nutshell PO = CEO of the product
3. Insufficient collaboration with development teams: BAs are accustomed to working as intermediaries between stakeholders and development teams. However, as a PO, close collaboration with the development team is crucial. Failing to actively engage and communicate with the team can lead to misunderstandings, delays, and suboptimal outcomes. The PO should work closely with the team, provide clarifications, prioritize features, and ensure the team’s understanding of the product vision. Note that the Agile teams work in clear autonomy approach, give them the product needs and requirements and allow them to function in a manner where in their creativity can emerge and provide the right value for the customer.
4. Requirement-driven approach: BAs often have a strong background in gathering and documenting requirements. However, it is essential for a PO to adopt a more holistic and strategic mindset, considering the overall product vision, market dynamics, user needs, and business goals. Look beyond the obvious and there is a wealth of information on needs and wants of the customer there to be address and resolved.
5. Lack of user-centricity: BAs sometimes prioritize the needs and wants of stakeholders over those of end-users. This can result in a product that doesn’t effectively address user pain points or deliver value to the target audience. A successful PO should place a strong emphasis on understanding user needs, conducting user research, and ensuring the product meets user expectations, use approaches such as “Gemba” or “HMW – How Might We”. Use thoughts and elements from Liberating Structures.
6. Resistance to change and agility: BAs typically operate within defined processes and methodologies. However, a successful PO needs to be adaptable, open to change, and embrace an agile mindset. Resistance to change can hinder the ability to respond quickly to market shifts, adapt to feedback, and make necessary adjustments to the product strategy. At times the product as developed could be required to be changed once the requirements are developed, this is an iterative approach, we work and act as we learn more about the users, their issues, pain points, technology capabilities and so on. Agility is all about responding to change.

It’s important to recognize these anti-patterns and address them proactively. By understanding the challenges that may arise, BAs transitioning into the role of a PO can develop the necessary skills, mindset, and behaviors to be effective in their new position. Continuous learning, collaboration, and a focus on user value are key to overcoming these anti-patterns and succeeding as a Product Owner

Last few words of Wisdom:

Transitioning from a Business Analyst to a Product Owner is an exciting journey for professionals seeking to expand their impact in an Agile environment. By identifying skill gaps, acquiring relevant knowledge, and showcasing transferable skills, BAs can successfully upgrade their role. Embracing continuous learning, collaborating with experienced practitioners, and gaining practical experience will empower Business Analysts to become effective Product Owners who drive value and contribute to the success of Agile team. Remember one key element – Product Owner is the Value Maximizer in the game.

Product Owner Needs to Master “The Art of Saying No”

One skill that a Product Owner should master is “The Art of saying No.” One does not have to please everyone and make a mess of the product and the value it provides to your customer.

Saying ‘No’ is an art, and it is not easy when you have management, stakeholders, sponsors, end users, and your Agile team as part of the game. You must engage them for all the right things to be done in the right way and the wrong things to be done in the right manner.

It is important to note that the primary responsibility of the Product Owner is to maximize the value, and to do this effectively, he needs to be empowered. 

The Product Owner should be like the CEO of an organization. Consider the product to be an organization and the PO to be its CEO. Remember, a successful product solves/resolves the customer’s pain areas or challenges, enabling the smooth functioning of the business. A good product evolves over a period of time, and features and functionality are not built in from Day 1. 

Visualize the current version of iPhone and its earlier versions like iPhone 5 or 6. It has evolved immensely. We cannot think of all the features and functions on Day 1; we learn and grow as we observe, use and get regular feedback.

You need to evaluate competitors’ products and evolving technology, think five years ahead of the current times to identify the needs of the future, and start to put them in our blueprint. You ought to lead the pack, not copy and follow others. Instead of focusing on Best Practice you should work on Next Practice, which would be the new best practice for the world.

There is a famous quote that states, “We should learn to say the slow Yes and quick No.”

To be a good CEO, one should know the needs and requirements of stakeholders and how to handle them. Do we treat all stakeholders equally and have a common communication strategy across the board? Do we consider the information required by our stakeholders, investors, and management when developing a communication plan? 

Designing the communication strategy would help you to more effectively say “No” when you understand the ‘Why’ and ‘What’ of your communication game plan. Product Owner should not be thinking about consensus every time. It may not always be a good practice and may hurt the product in the long run.

Saying ‘No’ is an art. You need to know how to phrase a sentence and what would form the most appropriate way to start the sentence when intending to say No. One could respond by:

• That is an interesting idea, however 
• I hear what you are saying and 
• I understand that this is important to you, however
• If I would say Yes to this, then 

Define and identify your approach depending on the stakeholder and current situation. You do not need a cookie-cutter strategy. Learn to understand the psychology of your requestors, and the impact that your response would have on them. Also, understand the product, the requestor’s behavior towards you, your team, funding, and support (it is all politics at the end of the day).

Remember, Product Owner’s thought process is not to say “No” to everything. The goal is to say No to good ideas so that you can say Yes to great ideas.

Different ways of saying “No”

Crystal Clear –This method of saying no is suitable when you have a strong relationship in place and there is enough trust between the stakeholders and the product owner.

Timing Based – This approach would be critically deployed when you are facing issues with deadlines and milestones, as per the statutory & regulatory needs. The ideas which are nice to have and do not meet the timeline criteria should be kept on the back burner.

Impact Management – Evaluate the impact of saying Yes vs. No. One person’s gain would be another’s pain. Before arriving at any decision, analyze the impact of your decision on the stakeholder, considering the product vision, market impact, competition, and so on. Compare the present request with other requests from different stakeholders and perform a CoD (Cost of Delay Concept) for comparison.

If-all-else-fail – Use this approach when all the other techniques have not yielded results or failed for you. This should be your last resort. Use this approach for stakeholders who fall under the category of High Influence and Low Impact. When using this approach, ensure that you have the backing of your key and important stakeholders.

Levels of Communication

When communicating with anybody, it is crucial to consider the following: 

1. Start with understanding your emotions and those of others
2. Analyze your relationship with them and their relationship with your product/service
3. Adopt the process
4. Construct your message
5. Communicate

Speaking about emotions, consider whether you are calm, relaxed, anxious, or upset. This process can make or break your approach. If you are comfortable with your emotions, move forward and answer a few questions. 

• Have you spent time building your relationship?
• Has the stakeholder developed a close affinity with you and your product?
• Will they promote your product in all situations? 

When speaking about the process:

• Think about how you are constructing your thoughts, phrasing, and developing your sentences,
• What tonality you are adopting?
• What is your body language?
• And how controlled are your facial reactions? Have you used a common vocabulary?

When communicating, have you seen your environment and the people around the place of discussion? How do you start your conversation? Where and how do you pause? Do you provide adequate time for the message to be accepted? Is there any scope for further discussion?

Do remember, this article is not about saying No, but it is about developing approaches to have great value in your product. It’s a guide to prevent the unnecessary stress of developing something that would not add / create value to the outcome and no true ROI would be achieved.

The thought process here is all about understanding how to manage the various types of stakeholders that you would encounter in your product development journey. How do you ensure that all features and functionalities just do not land up in your product? While you should not undermine the importance of any feature or functionality, it is important to identify the source of the highest ROI. Analyze what creates excitement in your product, what features can move to the next release, and so on.

Efficient Product Owners should continuously try to evaluate the direction of the product, how things are shaping up, and what they must do next in the journey. Equally important is that as a Product Owner, you do your retrospective and find approaches to doing things better.

As a Product Owner, if you cannot protect your product and maximize its value, rethink your approaches and strategies and understand whether you are doing justice to the role of the Product Owner or acting as a glorified scribe (Only writing user stories) for the product backlog.

The choice is always yours. 

Stakeholder Mapping – The Lost element / Missing Piece of our Jigsaw puzzle

So much data is written, spoken, taught and available across the industry on Stakeholder mapping and management and the best surprise or part is, that we all are still struggling to get a handle on this concept and engage our stakeholders in the right way.

I personally believe the basic problem is the one size that fits all approach that all of us apply and think it will always work. Stakeholders come in different shape, size and formats along with their own wimps and fancy, they need to be catered to, nourished and for a lack of idea – We need to do literally baby-sitting for them, but the worst possible element is that we doing just the opposite, we are painting the town RED and look and treat all our stakeholders thru the same lens and 100% similar approaches. This strategy is bound to fail and is actually failing, and we are not learning from the same.

Once again … I shall throw some light on elements that have worked for me, will they work for you, not sure but it would worth reading and relating to your own concepts.

As much we do stakeholder mapping in the initial stages of the project, this concept is always ever-going, it is like Risk Management – to be done on a continuous basis, as stakeholders would change, move out of your engagement, new ones would be added, business dynamics could incur changed, environmental conditions will bring different levels of changes, there is no standard recipe here.

Recommend developing a stakeholder mapping document, this is a visualization document that helps clarify positions and interest of each stakeholder category and individually, it helps to identify the supporting factors of the stakeholder including power structures with in the system.

This analysis helps identify all characteristics of the interest group, their relationship among themselves and serve the purpose of effectively communicating with them.

Draw initial observations about the alliances or power structures along with conflicts between stakeholders (we all know that there is a decent amount of politics in all organizations), we do not want our projects to get stuck in this mess and have clear ideas on management of our deliverables.

Steps to develop Stakeholder Maps:

• This would involve a SPOC from the organization, who is has connections internally in the system, who knows the system inside-out.
• 1^st level brainstorming happens with the SPOC and a few select members of the scrum team
• Define and use different symbols for connections. E,g, for more complex elements use broken lines.
• When developing the map, consider the following:
  • Why this project?
  • What are the goals and objectives at Business Level, Department level and Org level?
  • Who will benefit from its success?
  • Who has an interest in the project getting successfully rolled out?
  • Who could be your potential showstoppers?
• This would lead to a draft level stakeholder map, which then needs to be validated
• This entire activity of creating the initial draft of the map would be around 60 – 180 mins which again depends on the complexity of the organization and number of stakeholders.
• Remember: it often takes time before all parties involved speak openly about themselves and their own needs and needs of their Business / department / organization.

This approach would help us obtain valuable information on how and when and what to communicate, what should be the format of communication? How often it should be done? Who all needs to be there, at times we also need to identify the personality profiles of our stakeholders, this would enable us to understand if they are detailed oriented or big picture view, as we do not communicate adequately and sufficiently (even though our information would be true and complete), we shall loose the focus of our stakeholders, if to a detailed oriented person we provide high level information and vice versa, it a just a disaster waiting to happen

The dynamics within the team, department and organization are hugely complex and critical. It is important for the Product Owner along with the Scrum team to understand these interactions, and for doing the same, stakeholder mapping as an activity is essential.

Generally, when defining stakeholders, it is important to move away from being generalist and one should be focused on being as specific as possible.

A good stakeholder map can be instrumental for your project success, Applying these principles would solutions worth its salt over a period.

Remember you need to have different approaches and strategies for dealing with the stakeholders who are interested in the outcome of your deliverables and the others who may not be on the same side of the coin as others or yourself. There is no one size that fits all approach.

A few final thoughts:

If you are involved in managing or leading a project, it is your responsibility to ensure the project is delivered successfully. It is up to you to deliver the project on time, to budget and to quality. Stakeholder mapping and stakeholder engagement is crucial to achieving these goals.

Product Owners should not under-estimate the power and value of stakeholder management and engagement, this could be a potential make/break of your assignment.

Gemba Walk – A method to collect requirements & observe current approach of working (Forgotten tool in the industry)

A Gemba Walk is the practice of Product Owners, Product Managers, Business Analyst personally observe the place where work is being done. The original Japanese term comes from gembutsu, which means “real thing” or “real place.” Thus, the Gemba is wherever work happens, and value is added to products or services. The Gemba may be a production floor, an emergency room, a construction site, or a classroom.

During a Gemba Walk, PO’s / PM’s should physically go to the places where people are putting together products or using them, helping customers, analyzing data, maintaining machinery, or any other process. The philosophy behind Gemba Walks rests on the idea that it is easier to gather feedback, spot process or workspace issues, and build trust with the team by observing work firsthand. Employees tend to be more open to pointing out opportunities for improvement or sharing concerns when they are in their own workplace.

PO’s / PM’s who have committed to Gemba Walks typically spend about 60 minutes a week at the Gemba. They pay careful attention, ask questions, and observe processes, The idea is to catch on ground information and understand the nature of work getting performed

Some Tips on doing a GEMBA walk:

• Define a clear focus – In terms of what is to be observed? Who is to be observed? What is the purpose and scope of my learning?
• Communicate with the Team Before the Walk:You don’t want your client / end users to feel blindsided by a Gemba Walk – it isn’t a surprise inspection, rather it is a technique for collecting requirements, it is essential to describe the purpose of Gemba Walks and let the team know what to expect. Open communication in advance will help people feel more comfortable and foster engagement.
• Pay Attention to the Handoffs: If you follow the value stream, you will likely find that all the stakeholders and output of that process along with the handoffs between processes, peoples, or departments. Those areas may yield the most potential for eliminating waste.
• It’s not about just observation: The process of capturing the information / data is very important.
• Separate Observations from Interpretation: Pay heed and attention to the methods of working, work around solutions as used, challenges faced, discussions between 2 people (do OSMOTIC communication – do not participate)
• Pay attention to routines and details: Qualify how long a work takes (measure it), Quantitative analysis can be easily visualized with charts and graphs and more meaningful insights can be obtained.
• Based on all of the above: Obtain new insights on how the problem is resolved today and how the process is lived in the real world
• Do not fire or make judgement calls.
• Follow Up: After your walk is over, be sure to follow-up with the teams, let them know what you learned and ask for additional input. It’s a good idea to close the loop so people aren’t left wondering about your impressions.

Gemba Walk Checklist

Every time when a PO / PM performs a Gemba walk, they will need to prepare a checklist in advance. This list will help them focus and target their efforts in right direction.

The checklist has to include questions that will help understand the process that they are going to observe in a better way. Questions may vary depending on the theme of your Gemba walk.

Here are some basic Gemba walk checklist questions:

Use Gemba walks a means to collect needs, observe the current behavior and work as performed, challenges, If possible speak to end users or doer’s of the process, understand their needs and viewpoints.

Perform this activity for multiple days and across different segments of people, this would enable you to focus on different situations and scenarios that may come up.

Empathy – A tool for better understanding of our end users and solution users

Several times in my career, I have heard many people / gurus say to use Empathy as a tool to better understand your customers and their needs, their behaviors’, their pains, and their future outlook. The idea is empathy would only provide the experience from the past and not give any new insights in the needs and requirements of the future.

A lot of us (including me) get confused, when we speak about Persona and Empathy … are they similar concepts, do they capture and provide similar information, how are they to be used, when are they to be used, what is the value proposition of using them, which one is a better approach?

This document of mine would try and shed some light on the Empathy part and hopefully in future we shall explore the depth of Persona also.

Empathy map is a tool for target audience analysis. It is used to identify feelings, thoughts and attitudes of existing or potential users / customers and understand their needs, The idea is to obtain in-depth insights on potential users by means of what, why and how questions. Empathy maps focus more on the emotional state of customers.

Let’s first focus on the usage and value that Empathy would provide:

• It would help us better understand and appreciate insights from testing or observations with the users and capture different perspectives
• Helps understand where the user has problems or potential benefits
• Helps to collect findings to build Persona

Empathy map as a tool should be used in conjunction with other tools like Customer Journey mapping, Persona / User Profiling and Value proposition canvas

When doing Empathy mapping with the customer, ensure that we have 2 people, one person documents and records the information while the other would-be posing questions. Typically, this should max 30-45 mins of session

Use a template for Empathy map where you record everything about the customer such as:

• Think & feel
• Hear
• See
• Say & Do
• Pains
• Gains

Use questions such as:

• Where is the customer? What do they see?
• Who influences them, with whom do they interact / communicate?
• What emotions are driving the customer
• What does it say about their attitude?
• Where does the customer behave in a contractionary manner?
• What are their biggest challenges / pain areas?
• What are the opportunities and benefits they may have?

While doing this exercise, focus on human values – like thoughts, opinions, feelings, emotions (at times these may not be directly available, you have may to infer based on their body language, tone, word selection).

Pay special attention to contradictions, often we can identify something new from what the customer says and the way they behave.

Using this data, analysis all the edge cases, dig into unique behaviors and identify what are we building … why are we building, will it serve the purpose?

Empathy mapping is a unique tool that a Product Owner or a Business Analyst should have in their armory to better serve and engage the End User community, better your tools, product and services are aligned to the end user … higher is the potential for your products to dominate the market.

Again it should never be one size that fits all.