Author: Angela Wick

3 Reasons Value Needs to be at the Center of Your Project Triangle

Written by Angela Wick on September 6, 2016. Posted in Articles. 2 Comments on 3 Reasons Value Needs to be at the Center of Your Project Triangle

Over the years, I’ve helped many teams find success by identifying and removing roadblocks.

One roadblock that seems to be appearing with greater frequency is “project prominence”— an emphasis on the project over the product or solution being delivered. Teams spend so much time and energy debating, controlling, managing and measuring the project process, that they lose sight of the product and the value the project is looking to deliver. The needs of the end-users and the goals of the organization become secondary.

The difference between project and product might seem subtle at first, but it becomes quite obvious in practice. The Project Management Institute (PMI) defines a project as “a temporary endeavor undertaken to create a unique product, service, or result.” The product is the unique output of a project—the project builds the product. Many teams do not think of their solutions as a product, but the definition of product is quite broad including tangible items that can be sold in stores, as well as new software, bug fixes, process enhancements and really anything made to be used or sold (Merriam-Webster).

In practice, teams that emphasize projects:

focus on team operations
measure project phases, % complete, documents, timelines, deadlines, budgets, bugs, resources, etc.
debate how to optimize project operations
make decisions based on the team’s needs

Whereas teams that emphasize products:

focus on value
measure value delivered, end user satisfaction, speed to value, and learning
debate how to make a solution more valuable to the end users and the organization
make decisions based on end user needs and/or strategic goals of the organization

One way to reduce the emphasis on projects is to help your team rethink the Iron Triangle (aka the triple constraints of project management). The standard iron triangle usually looks something like this:

This approach assumes quality is achieved by controlling/balancing schedule, cost, and scope. If any of the constraints spiral out of control, the quality of the solution will suffer. If scope gets too big, schedule and resources (cost) must increase or the project quality will suffer. If the schedule gets too tight, the scope needs to be reduced. If the project overruns its deadlines (schedule), the cost will go up. You can’t change one, without impacting the others.

But, what if we modify the Iron Triangle to this:

Is this really different? Is it just semantics? Aren’t quality and value really the same thing? They aren’t the same! Value adds a dimension to quality—emphasizing that the quality of the solution matters only to the extent the user and organization derive value from an increase or decrease in quality. Keeping value at the center shifts everyone’s thinking away from the traditional project management approach to a product approach. Cost, scope, and schedule are only as important as the impact they have on the value delivered. I’ve found that putting value at the center of discussions about schedule, cost, and scope helps teams in 3 ways:

Teams Stay Focused on the End User

When quality defines success, it becomes possible to deliver high-quality solutions (minimal defects, no missed deadlines, no cost overruns) that no one wants or needs. That’s why usability, usefulness and/or value need to be part of the discussion.

Product value provides a strong foundation for every project. Strong teams start each project by exploring context in terms of product value and keep questioning value throughout the project lifecycle.

Teams Make Better Decisions

The value perspective helps you make better decisions throughout the project lifecycle. Teams that make decisions based purely on cost, schedule, and scope, miss out on opportunities to maximize value. It might be ok if the project goes over schedule and over budget when the team discovers additional scope that dramatically boosts value. It might be ok to miss milestones or leave parts of the project incomplete if those components do not provide value, or provide minimum value compared to the required cost and resources.

Strong teams minimize project metrics focused on operations, and create useful data that gauges cost, schedule, and scope in terms of product value to the end user and the organization. When value is already embedded in the data, value becomes the driver of decision instead of process quality. Teams stop making decisions that benefit them and begin to develop empathy for the end-users.

Teams Become More Agile

Putting value at the center of all discussions and decisions is the easiest way to bring agility to your project. The focus on product over project helps teams adapt. They embrace changes with confidence because the “why” makes so much more sense when change is discussed in terms of the end goal (user satisfaction) rather than the process. It brings relevance and context to change.

High performing product teams have a shared understanding of value that makes the need to change obvious. Teams become more adaptable and efficient as they streamline processes to focus only on what needs to be done to deliver a high-value product.

So, how do you bring value into discussions about timeline, budget, resources, documents and deadlines? Frame questions with value:

How do these metrics measure end user value?
Why is this deadline important to the end user?
How does this deadline maximize value?
Is this deadline early enough to leverage the value the solution provides to the end user?
How much are we willing to spend to provide this value?
What do we need to learn to increase the value we can deliver?
Are we spending more than the value the solution will apply?
Do these project tasks/documents provide value to the end user?
Do we have the right resources to deliver value to the end user?
What is the smallest scope needed to provide value?
Are there areas of scope that don’t provide value? Is this just enough to provide value and meet end user needs?

’m not saying that project operations, methodologies or frameworks are evil. Instead, I am encouraging you to take a look at your team and determine if you have a project prominence roadblock. Does your team emphasize project operations at the expense of product value? Your outcomes will improve dramatically if you let product value lead and smash through that project roadblock.

Is Your Project Manager-Business Analyst Collaboration a Pressure Cooker?

Written by Angela Wick on April 11, 2016. Posted in Articles. 3 Comments on Is Your Project Manager-Business Analyst Collaboration a Pressure Cooker?

Is your project’s red-yellow-green status for requirements based on percentage complete of the requirements document?

Or percentage complete of the JIRA stories documented?

Maybe this is why requirements are taking so long!

Is the focus on the status of the document or the progress toward shared understanding of the problem and solution?

{module ad 300×100 Large mobile}

It is important to honor the priorities of both the project manager and the business analyst. One can’t win out over the other or the end users might suffer. So, how do we find the right balance? How do PMs and BAs come together to support each other while standing up for the essence and integrity of their roles?

Project Managers – Do you know what it takes to collaborate with BAs to get great project results? Are you encouraging BAs to be leaders of their domain?
Business Analysts – Do you understand the value of the BA role and how the PM can support and enhance your practice?

Tight timelines and fixed solutions apply tremendous pressure to interactions between PMs and BAs. The pressure triggers negative PM and BA behaviors. I’ll highlight some of these behaviors below and offer insight to inspire better collaboration.

Pressure #1: Tight Timelines

Tight timelines put pressure on the entire project team. When documents like BRDs are tied to unreasonable durations in the project plan, BAs feel like document dispensers:

Tight Timelines Mindset to Change – Get documents done NOW!

What does the “Get Documents done NOW” mindset look like:

The PM lets the BA know timelines are really tight.
The PM asks the BA to draft documents ASAP.
BAs start filling out templates and then use the review process as an elicitation technique to get them reviewed approved “quickly.” (FYI-It’s not faster! It’s actually a long, painful process that stakeholders loathe, BUT…)
Stakeholders get used to reviewing text-based documents and tolerate the process because it’s the only process they know.

Tight Timelines – A Collaborative Alternative

Modern PMs and BAs understand the drawbacks of the “write-review-repeat” cycle—it actually takes longer and produces unstable, ever-changing requirements.

Related Article: A Collaborative Stakeholder Process

Why? Well, because the team never gets a chance to collaborate and develop a shared understanding of the big picture and the real problem the team is trying to solve. They only understand their piece of the puzzle and cannot see connections or gaps that may have prevented defects or maximized the value of the solution.

Instead of forcing text-based document review from day one, the team should support a requirements process that includes dialog and analysis with stakeholders. The BA should be using elicitation and modeling techniques to facilitate structured conversation with stakeholders about the current state, future state, people impacted, process, data, rules, etc.

Once there is a shared understanding, document writing, review and approval move along quickly. Overall, this collaborative approach is faster and yields higher quality requirements.

Tight Timelines Mindset to Change – Minimal BA Planning

What does the “Minimal BA Planning” mindset look like:

The PM owns the project plan. (What BA plan?)
The PM sets a milestone for requirements sign-off or sprint commitment on the plan.
The PM focuses on the date/deadline and the document (or tool) vs. the quality of the requirements process.
BAs may or may not have experience or training in creating BA plans and a quality requirements process. Either way, they may follow the PMs plan without discussion or negotiation.

Tight Timelines – A Collaborative Alternative

PMs should encourage BAs to design their own approach. PMs and BAs should collaborate on the plan, timelines, who is involved, and what is truly needed to get to good requirements. The team should meet with the sponsor and get agreement on the quality expected and plan for requirements accordingly.

Tight deadlines may be ok if time and cost are the drivers of the project. Rework and quality issues might be worth the pain to get it done by a date. But, if quality, user experience, data integrity and getting users to love the solution are the drivers, then speeding up requirements and focusing on deadlines and documents will spell disaster.

Pressure #2: Fixed Solution

It’s always surprising to me how common it is for project teams to start their work wearing the blinders of an assumed solution. BAs are basically asked to reverse engineer requirements for a solution that floats down from above:

Solutions tossed down to the BA, before analysis, tend to promote the following behaviors:

Fixed Solution Mindset to Change – Don’t Ask Questions!

What does the “Don’t Ask Questions” mindset look like:

The stakeholders communicate their want (not their true needs).
The stakeholders (sometimes on their own) identify a solution, and it is rarely a complete solution that is analyzed and well thought out.
The PM and the stakeholders pressure the BA to crank out a requirements document.
No one explores the true needs of the end-user and, therefore, no one knows if the predefined solution meets the true needs of the end-user or the organization.
Gaps/issues are ignored, placed in a parking lot, or found along the way or after go live, creating a long backlog of enhancements.

Fixed Solution – – A Collaborative Alternative

In my experience, stakeholders rarely ask for the right solutions. There is always more—a twist and a turn that yields a different solution than requested. Rushing a solution that was never really vetted, yields endless scope changes, increased defects, and unhappy users.

That’s why, as tough as it is, BAs need to appropriately challenge predetermined solutions and help their stakeholders think.

PMs need to support the BAs, even under tight deadlines, to explore true needs and generate options/alternatives. The PM and BA should work together to help the sponsor understand the risks of moving forward without analysis.

Fixed Solution Mindset to Change – Deep Rooted Bias

What does the “Deep Rooted Bias” mindset look like:

Everyone (PMs, testers, developers, product owners, end-users, etc.) is aware of the solution at the beginning of the project.
The sponsor and the stakeholders agree to validate the solution.
The awareness of the predefined, but not yet analyzed solution creates bias that limits the team’s ability or motivation to see/identify alternatives.
The BA doesn’t push for deeper discussion because the team is ready to move forward with the stakeholders’ plan.

Fixed Solution – A Collaborative Alternative

The BA’s primary role is to advocate for value! This should be a ruthless focus—much more important than the perfect document. BAs need to courageously ask the PM and the team for time to make sure the solution is value-oriented, not just first-idea-oriented.

Easing the Pressure

A collaborative partnership between PMs and BAs requires:

• PMs and BAs who understand their role and are leaders of their domain.

• PMs and BAs who can clearly communicate and advocate their perspectives and priorities.

• A shared understanding that trust and teamwork will maximize solution value.

How do you build bridges between business analysis and project management in your organization? Please leave your comments below.

5 Lessons from Working with Agile and Waterfall Teams

Written by Angela Wick on April 13, 2015. Posted in Articles. 4 Comments on 5 Lessons from Working with Agile and Waterfall Teams

Over the course of my career, I have always been intrigued by leaders who promote a specific methodology or tool or process as THE RIGHT WAY to deliver solutions. They dispense mandates and proclamations to promote their all-or-nothing, purist approach to methodology. Typically it is because it worked in the past for them, and once it fails to deliver results onto a new one.

I’ve seen so many CEOs, CIOs, CoE leaders, and technology directors come and go with their unique methodologies and approaches. Do you know what doesn’t change?—the way BAs do work to be successful; The BA mindset, the key tasks and core set of techniques, remain constant.

We may need to use a new tool, try a new technique, a different template or learn a new set of acronyms, but the mindset, tasks, toolbox still work regardless of methodology.

Success and failure do not discriminate by methodology either. I’ve worked with teams that consider themselves Waterfall, Agile, hybrid or generic. I’ve seen huge success and mind-numbing struggle in all types.

I find myself in the midst of the following questions and thoughts often: Does methodology really matter? Does the BA role change based on the project approach? Are Agile and Waterfall really opposites? Can we apply Agile principles to traditional environments? Is innovation really dependent on a particular methodology? How can we boost collaboration regardless of methodology?

Here is what I’ve learned about Agile and Waterfall approaches:

1. We need more collaboration in EVERY project.

What happens after your morning SCRUM or status meeting? Does everyone wander back to their cubes and belly up to their keyboards for the rest of the day, and meander into boring meetings?

Collaboration should be an all-day event! The occasional prairie-dog-pop-up to ask your neighbor a question is not enough. That’s not collaboration!

Lightening does not strike at your desk—you need to get up and get moving. Good collaboration is physically and mentally engaging. It’s not sitting at your desk or lounging around a conference room table. It’s a group of active people standing at a whiteboard with lots of dialog and movement. It’s a small group taking a walk and sharing ideas.

What about conference calls? Meaningful collaboration is harder over the phone, but it’s possible. Virtual collaboration does not involve one person reading a document and asking for feedback. It’s a group of people—not multitasking but—adding, moving, deleting from a virtual whiteboard. It’s a lively discussion where everyone contributes.

Even after years of Agile, many organizations still don’t collaborate enough. Too many teams still delegate work to individual desks and then throw it over the cube wall to their sequestered neighbors.

Teams should use collaboration techniques to see the big picture, to fully engage all stakeholders, and to generate more conversation and dialog.

2. Agile projects have BA tasks.

“Agile” roles, like Product Owner and SCRUM Master, are not all encompassing, neither are any of the Agile methodologies. They are not meant to accomplish everything needed to deliver a solution. Traditional BA tasks are still needed in Agile. You may or may not need the title of “BA” to do those tasks, but the tasks remain relevant.

Planning, monitoring, business need definition, communication, elicitation, requirements validation, traceability, etc. still happen in all projects. The factors that change might include timing, duration, emphasis and documentation. Rigor and adaptability might vary as well, but the basic BA tasks apply in all projects.

In an Agile project environment, you might replace the 400-page requirements document or the exhaustive, step-by-step process models with an evolving prototype or a sticky note-filled whiteboard with dry erase arrows. Either way, the fundamental tasks remain the same despite methodology. The BA uses many of the same techniques to get to the differing outputs. They may use the same technique more or less collaboratively. I hope it’s more collaboratively no matter what approach is being used.

3. Techniques don’t change.

Just like BA tasks, BA techniques don’t change based on the project methodology either. You may try new techniques in new ways at different times, but, all in all, good techniques can be used in Agile and waterfall environments.

Traditional methodologies require techniques for requirements elicitation, analysis, prioritization, change management, issue resolution and more. Projects using an agile approach require techniques for the same functions. It’s really just the external stuff that changes—the timing, structure, format and process. Certain Agile methodologies use a specific set of techniques (SCRUM  User Stories), but they are not all encompassing for requirements activities, they are a minimum to start with, a placeholder for conversation and more collaboration to follow.

We need to elicit requirements from stakeholders for every project. BAs on traditional projects might elicit all requirements at the beginning of the project. BAs on Agile projects might elicit requirements in one small chunk at a time, but the techniques are similar.

4. Stop Polarizing Agile and Waterfall

Agile and waterfall are not opposites—they are not mutually exclusive. Agile is not meant to be a polarizing force that pushes teams away from Waterfall.

Agile is a mindset born from the Agile Manifesto written by 17 men, probably on a napkin, at a Utah resort in 2001. Have you read it? It’s remarkably simple and packed with common sense:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over Processes and tools

Working software over Comprehensive documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

The intention of the Manifesto was not to replace a particular methodology—instead, the authors wanted to bring visibility to what works to build better software by:

Balancing the scales and slide away from the slow, document-heavy, procedural methods of the time
Bringing flexibility and fluidity back into the world of software development
Creating an efficient and effective process that would bring meaning and purpose into every task

Take note: The manifesto offers values, not demands, process, or requirements. They are meant to guide or refine, not constrain. These values can be applied to all projects.

I don’t think the authors of the Agile Manifesto meant to create such polarization in the industry or organizations and their practices.

5. Don’t freak out your stakeholders.

So given the simple foundation of the Agile approach, the transition to Agile does not need to be an historic event full of pomp and circumstance. Yes, Agile looks and feels a bit different than waterfall, but that doesn’t mean you need warn your stakeholders about major changes. Many of the agile principles can be implemented well on Waterfall projects without alarm or need for major change management. It takes relationship skills, facilitation skills, and confidence.

It is important to help all stakeholders understand the agile mindset, but we don’t need to overemphasize differences. Think about it this way: Why and how will it look and feel different? Is Agile driving the differences or is it just a better way of working?

It really doesn’t matter what it’s called, you just need to help stakeholders understand the value and move them forward gently. Any methodology done well will provide stakeholder value. Keep them focused on the output and how the process gets them to the value. As long as you are efficient, organized, effective, you will keep stakeholders engaged.

It may be the comfort of governance and process they are missing the most when transitioning to Agile. Help them through this, but don’t let it get in the way of being more collaborative and value minded working through requirements.

So, now that I’ve had my say, do you agree?

Don’t forget to leave your comments below.

A Business Analyst’s Best Friends: The Project Manager

Written by Angela Wick on July 15, 2014. Posted in Articles. 5 Comments on A Business Analyst’s Best Friends: The Project Manager

FeatureArticle Jan22 Wick Successful BAs position themselves in the eye of the project storm. They are the calm, center point of a complex group of interrelated people, roles and processes. BAs are in a prime position to ensure—when the project storm settles—that all pieces are connected and aligned to maximize value to the organization. In order to do this, BAs rely on strong relationships with many friends.

Last month, I set the stage for a series that describes the BA’s best friends. Each month, using the following questions, I will explore the relationship between the BA and one of their key stakeholders.

How does this stakeholder benefit from the BA?
What makes a top-notch BA from their perspective?
What frustrates this stakeholder most regarding the role of the BA?
How to say “no” to this stakeholder?
How to influence this stakeholder to give you what you need?
How to communicate the value of the BA to this stakeholder?

Without further adieu, please allow me to introduce THE PROJECT MANAGER.

Obviously, the BA’s relationship with the project manager can vary based on the structure of the organization; the project size and structure, and the experience level of the BA or the PM.

Despite these variations, the key components of the BA/PM relationship are collaboration and communication. The BA and the PM must work closely together to manage solution scope, risks and stakeholders.

How does a PM benefit from a BA?

Scope, schedule and cost are the Project Manager’s primary concerns. PMs rely on BAs to provide timely information about anything that might impact scope, schedule and/or cost.

Because the BA is positioned at the center of an active and evolving project, they are the eyes and ears of the project manager. BAs see details that the PM may not—connections between people, processes, products and timelines.

The key word here is timely. BAs need to understand when to communicate potential scope, schedule and cost impacts to the project manager. In most cases, sooner is better than later. Proactive communication gives the BA and the PM time to plan an approach.

Obviously, collaboration and communication are two-way streets. The PM needs to communicate context and details with the BA. I often hear from PMs that their biggest fear of BAs is “scope creep.” Fearing that BAs will promise things to stakeholders that increase the scope of the project beyond what the PM has planned. There is a balance here that I hope each BA takes very seriously. The balance is value vs. scope boundaries. The BA role needs to collaborate with the PM and champion scope changes where the value of the solution is at risk, while ensuring that scope changes that do not add value are kept at bay.

What makes a top-notch BA from the PM’s perspective?

The PM wants timely information from the BA. Top-notch BAs will do more than present a problem. They will present the issue and an approach, or a few potential approaches. Top-notch BAs keep the PM informed, ask for help when they need it, stay connected to other BAs and project teams to help PMs see impacts, build great relationships with stakeholders, build trust and ease users into changes.

Top-notch BAs have a broad vision. They can focus on the detailed requirements, but they understand how their piece of work fits into the larger project and organization at large.

Top-notch BAs offer strategy. They understand how pieces of the organization connect and how they align them to give the organization value.

Top-notch BAs use the PM’s time well. They come prepared to meetings with a list of questions and concerns and approaches. Be efficient with the PM’s time. If you don’t have a regularly scheduled team meeting with your PM, then set a recurring appointment with them so that you have time each week to touch base. Provide a simple, concise status update each week, indicating things that might impact schedule, scope and cost.

What frustrates a PM about the BA role?

Scope creep is arguably the biggest fear PMs have about BAs and their work. Successful PMs deliver projects on time and within budget. Scope creep is the biggest threat to project management success.

In many cases, project managers are pressured to give firm cost estimates and implementation dates before the scope of the project is clearly defined. This means PMs need to understand how the elicitation and requirements process is evolving. Are BAs uncovering issues that could impact timeline? Are new business needs being uncovered? Are risks avoidable without impacts to time and cost?

A great BA knows the scope and objectives of the project and gathers requirements that link back to them. Through the requirements process, the BA ensures that users asking for other requirements (not in scope) are managed effectively, and requirements gathering sessions are not reeling in “features” that are not in the scope of the project.

The BA understands when scope should be changed in order to ensure the success of the project and communicates these concerns to the project manager in a timely manner.

How to say no to a PM?

Sorry to answer a question with a question, but — why would a BA need to say no to a PM? Here are a few examples:

The PM sets an unreasonable deadline for the completion of the elicitation process.
The PM only budgeted half of the BA hours needed to effectively support the project.
The PM asks you to prioritize her project above the work you are doing on another project.
You discover a new feature that is required for the project to be successful but the PM says you need to move forward without the scope change.
You uncover a risk that needs to be addressed. Proper mitigation would delay the project and add significant cost. Your PM does not agree and directs you to move forward.

So how do you say no?

Well, we all want to be successful. One way to say no to a PM is to help them understand the situation in the context of their definition of success. For many project managers, a satisfied project sponsor is the definition of success. For other project managers delivering the project on time and within budget equals success. I have even worked on some project teams where success involved convincing the stakeholders to cancel a project.

Ask questions or provide information that helps the PM key in on how his ability to be successful might be affected; focus on the risk:

If my requirements elicitation or analysis time is cut, critical requirements will be missed that will delay user acceptance or cause issues at implementation that would be extremely costly to the project in terms of customer satisfaction, cost to fix issues and value ultimately delivered.
I need to focus on this project right now, but I will meet the deadlines we agreed on for your project.
The project sponsor will not be satisfied with our product if we move forward without this feature.

As I said before, timely communication is the key. Don’t wait to tell the PM two days before a deadline that you need more time. Don’t fully elaborate requirements for a new feature before you notify your PM. Communicate your version of no as soon as it makes sense.

How to influence a PM to get what you need?

As a BA, the primary things you need from the PM are support and information. BAs need to understand the expectations and priorities of the larger project team and the organization. The PM is a key resource for this information.

The PM also offers support and back-up for the BA, often in the capacity of protecting scope and timeline. PMs can help the BA get key stakeholders to participate and is an escalation point for helping the BA resolve issues that are impeding progress.

A BA needs to help the PM see consequences if the needed information of support is not provided. The consequences should be in terms of scope, cost and schedule. That is the language of the project manager.

In order to clearly define the scope, I need to get some quality time with this key stakeholder.
In order to meet my deadline, I need your help to escalate this issue.
If we don’t find a way to mitigate this risk, the product delivery will be delayed by three months.

How to communicate the value of the BA role to a PM?

Ask them what success looks like for each project and then tell them how you can help them be successful.
• Build trust with stakeholders
• Keep open communication on schedule, risks and issues
• Help manage scope

Your Thoughts?

BAs: How do you build trust and promote collaboration with PMs?
PMs: What are the characteristics and skills that the best BAs bring to a project team?

This article is the second in a 13-part series about BAs and their best friends. Next month’s friend: The QA Lead

Don’t forget to leave your comments below.