Voices on Project Management

by , , , , , , , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with - or even disagree with - leave a comment.

About this Blog

RSS

View Posts By:

Cameron McGaughy
Marian Haus
Lynda Bourne
Lung-Hung Chou
Bernadine Douglas
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Mario Trentim
Jen Skrabak
David Wakeman
Roberto Toledo
Vivek Prakash
Cyndee Miller
Shobhna Raghupathy
Wanda Curlee
Rebecca Braglio
Rex Holmlin

Recent Posts

How Portfolio Managers and Business Analysts Can and Should Collaborate

The 3 Things That Transcend All Project Approaches

Want Satisfied Stakeholders? Guide Them Through a Learning Process

There Are No Free Steak Knives

When Is A Project Actually Over?

How Portfolio Managers and Business Analysts Can and Should Collaborate

By Jen L. Skrabak, PMP, PfMP

 

Just like portfolio managers, business analysts are gaining wide acceptance as a profession. Business analysts can now earn their own PMI certification (PMI-BA) and read their own practice guide (Business Analysis for Practitioners). (Here’s a piece of cultural trivia: Did you know the latest bachelor on the reality TV show “The Bachelor” is a business analyst?)

 

Portfolio managers should get to know business analysts in their organization, because they can help ensure alignment and management of the portfolio to achieve the organization’s strategic goals and objectives.

 

What exactly do business analysts do? They, well, conduct business analysis. That’s defined as:

 

  • identifying business needs

 

  • eliciting, documenting and managing requirements

 

  • recommending relevant solutions 

 

With this in mind, there are four major ways that portfolio managers can leverage a business analyst:

 

1) Develop Pipeline Opportunities

 

Business analysts can play a critical role in analyzing business problems and opportunities that will eventually be used to initiate projects and programs in the portfolio. Product or technology roadmaps can outline potential projects or programs that will be initiated at future points. They’re also valuable during a project because they can support proposed changes to a project scope (which will affect the overall portfolio) and ensure that the business justification for the project or program remains valid. 

 

Many business analysts are embedded within business areas and are critical to early identification and understanding of future opportunities or changes to the portfolio.

 

2) Define Needed Business Capabilities

 

We often think of business analysts as documenting business requirements.  Those requirements are built upon an understanding of which capabilities are needed for a particular business domain. 

 

Typically, capabilities are based on the goals and needs of a particular business area. Those needs may be depicted through business domain capability maps, end-to-end process flows or functional diagrams. An assessment of whether the capabilities currently exist or not becomes the basis for identifying priorities and gaps (in processes or talent). It can also be used to benchmark against other companies.

 

3) Develop Business Cases 

 

With their high-level understanding of the goals, objectives and needs of the enterprise, business analysts can assist in defining the justification for the proposed solution. The basis of a business case is the needs assessment. This process seeks to understand the underlying business problem, assess the current state and perform a gap analysis against the future state.

 

In addition, the proposed solution (see #4 below) is needed for high-level cost estimates that become the basis for the numerator of the ROI. The potential return (denominator of the ROI) is also based on an analysis of the impact of the solution on the current process.

 

4) Perform Solutions Analysis

 

One type of solution analysis is to assess a variety of options to go from the current state to future state. (For example, process changes vs. system implementations.) Business analysts can work with business stakeholders to define immediate solutions (quick wins that may be process changes) or longer-term solutions (new products or systems). 

 

Business analysis outputs provide the context to requirements analysis and solution identification for a given initiative or for long-term planning. Business analysis is often the starting point for initiating one or more projects or programs within a portfolio. The analysis is an ongoing activity within a portfolio as the business environment changes and more information becomes available, creating new competition and strategies.

 

How do you work with business analysts? Share your experiences and best practices in a comment below. Also, if you’re looking to learn more about how business analysts can support practitioners, check out this pmi.org webpage.

 

Posted by Jen Skrabak on: September 01, 2015 04:37 PM | Permalink | Comments (0)

The Secret to Stakeholder Management

By Mario Trentim

 

According to Le Chatelier’s Principle, any change in the status quo prompts an opposing reaction in the responding system. Although Henry Louis Le Chatelier was a chemist, his principle applies to project management, right?

No project occurs in isolation: Each inevitably disturbs the environment because it stems from the organization’s structure, politics and strategic objectives. So, it’s no wonder that some projects can’t succeed despite a project manager’s best efforts.

To make things happen, you need a support coalition of powerful and/or influential stakeholders. But how can you get the necessary buy-in for a project?

Let me assure you: You will fail if you try to guess what is in your stakeholders’ heads. We all have a natural tendency to do that because, by nature, we feel uncomfortable with uncertainty and ambiguity. That explains why we are always trying to "fill the gaps."

What does this have to do with project management? Everything. Project managers must overcome two biases that pose obstacles to successful stakeholder management.

The first is that we see the project from our perspective, which leads us to narrowly identify stakeholders. Forgetting to include the project’s "hidden stakeholders" can be catastrophic.

The second, which I believe is bigger, is that we conduct stakeholder assessment and analysis with preconceived thoughts and distorted vision.

The secret to stakeholder management is obvious: You cannot catch fish using your favorite food as a bait. You have to use the fish’s favorite food!

When assessing stakeholders and strategizing how to engage them in your project, be sure to do your homework. When possible, ask your stakeholders directly about their expectations regarding the project.

This diagram offers an overview of potential stakeholder interview questions:

 (Monteleone Consulting, 2010Generic Questions for Interviewing Stakeholders”)

Of course, to a certain extent you need to be skeptical of the answers your questions elicit. My MBA students always ask me: How do you know if a stakeholder is telling the truth?

My answer is simple: you don't. You cannot tell for sure if a stakeholder is trying to manipulate the project (and you). But here’s a tip. Keep observing your stakeholders' behaviors and attitudes. Always put yourself in the stakeholders' shoes and discuss hypothetical scenarios with your core stakeholder management team.

Here is a worst-case scenario: I once had a sponsor who was against the project. I admit it took me some time to realize that he would do everything he could to make the project fail.

How did I discover the truth?

I’ll explain in my next post—don’t miss it. Until then, share your thoughts. What would you do in this situation?

Posted by Mario Trentim on: March 12, 2015 01:51 PM | Permalink | Comments (1)

8 Strategies for Gathering Requirements From Execs

Categories: Project Requirements

Project requirements are usually collected through an elicitation process, which requires employing various techniques and methods, such as discovery, analysis, understanding and validation. These methods can be applied in interviews, focus groups, questionnaires or requirements workshops. Typically, one or more business analysts will carry out the requirements elicitation process, while the project manager will be generally responsible for planning and setting up the requirements elicitation and management framework and for its outcome.

This approach might be applicable for various types of projects, but when gathering requirements from high-level executives — who don’t have the time nor need to know the details but who focus on the big picture — a special tailoring of this process might be needed. Here are eight strategies you or your business analysts should consider when collecting requirements from executives:

1. Prepare. Try to understand what their business priorities and objectives are. Find out in advance their preferred communication style. Get ready to collect the requirements in a short time and in an atypical environment — i.e., during a coffee break or lunch — due to their busy schedules (more on this point in number 5).

2. Simplify the process. Avoid going through checklists or elaborate discovery techniques. Instead, use a conversational approach, understand, guide and offer solutions and project pros and cons. Use visual depictions and summaries.

3. Simplify the language.Use simple and straight communication. Avoid technical language; instead, use examples or stories that relate to business problems and solutions.

4. Remain positive. Maintain a trustworthy attitude, be an adviser and be proactive. Instead of talking about issues or problems, talk about solutions and give details of what will work.

5. Focus on time.Consider that executives have many challenges to deal with, and hence the amount of time and attention they can allocate on a single topic is limited. Therefore, once you get their attention, stay focused and avoid wasting time. Remember: Time is money, especially for the C-suite.

6. Start with the outcome.The best advice I heard about communicating up is starting with the outcome. When you present solutions to their requirements, engage their attention by providing them an overview of the results first. Then they usually become more interested, creating an opening for you to tell them about the “how.”

7. Manage risk. Consider that some execs are sensitive to risk or can be risk-averse. If any of their requirements pose risks, prepare to develop risk mitigation and risk response options.

8. Maintain a strategic orientation.Focus on what the executives mostly care about — what impacts the business. In most cases, they’ll focus on a business vision, a product concept, innovation or financials (e.g., the outcome with the highest ROI).

What’s your experience with collecting requirements from executives? Have you employed any of these strategies? How did they work?

For more on requirements management, check out PMI's Pulse of the Profession® In-Depth Report: Requirements Management or visit the Requirements Management Knowledge Center of Excellence.

Posted by Marian Haus on: November 04, 2014 04:20 PM | Permalink | Comments (1)

Decomposing Requirements for Tangible Project Outcomes

Delivering scope or fulfilling needs on a project is not always equivalent with adding value. In my opinion, a project adds value to an organization if its deliverables add value. 

Many project managers approach the project in a delivery-oriented fashion. They plan for, work against, and monitor and control the project's work through deliverables. Delivery-oriented project managers make the scope's outcome tangible in order to fulfill the project's goals. 

The first step to incorporating this project planning technique is to understand what a "deliverable" is. "Deliverables" are concrete and discrete artifacts of a project's outcome, such as products, functionalities, features, documents and plans. They can be obtained by "decomposing," or breaking down, the project's requirements in smaller, more manageable components. 

As you decompose requirements, keep in mind that you can structure and manage the project deliverables in various ways. Some of the most common approaches for different types of organizations include:

  • Spreading deliverables across project phases. This is typical for projects conducted in a waterfall fashion and for schedule-oriented projects.
  • Spreading deliverables across knowledge areas. Project teams  organized by areas of expertise (such as operations, legal or  finance) usually use this technique in their projects.  
  • Spreading deliverable across processes. This is typical for process-oriented projects.
  • Spreading deliverables across sub-projects. This is most effective in big projects with added complexity, where deliverables are specific for parts of the project but not for the project as a whole. 
  • Organizing deliverables hierarchically, from major deliverables to sub-deliverables. This is best for product-oriented projects.
As a side note, in agile projects, where teams are action-oriented, the work decomposition is done slightly different. The focus then is on epics, user stories and on the functionality to be delivered.

To decompose requirements effectively, I recommend following these tips:

  1. Break down the work in deliverables and sub-deliverables by focusing on "what" to deliver. Remember that decomposing requirements happens during the early stages of the project. Don't ask "when" in the project phase it will be delivered or "who" is going to take care of it. Save these questions for later, when sequencing the project work and building the project schedule.
  2. Organize the deliverables based on their relation to each other. Use a graphical form, such as a hierarchical tree (i.e., work breakdown structure, or WBS), a relationship diagram or a mind map diagram.
  3. Avoid over-decomposition — that is, excessively breaking down or over-detailing work. This leads to micromanagement or inefficient work management. A good general rule is to decompose requirements to the point where you can estimate deliverables, costs and time, and verify and measure results. 
  4. Since you are dealing with deliverables and not activities, use nouns to describe each deliverable. Don't use verbs, adverbs or other action-driven labels.
  5. Verify the accuracy of the decomposition at the end of each level. Each sub-deliverable should add up to 100 percent of the deliverable above it. 
Focusing mainly and steadily on the "what" is a pragmatic and efficient planning approach as you set up the project.

How do you decompose requirements?

Learn about the basics of project work planning, including the four main steps of planning.

Posted by Marian Haus on: January 18, 2013 04:48 PM | Permalink | Comments (1)

The Scoop on Requirements Scoping

We've all been there. When a project's scope isn't properly managed, it can lead to schedule delays, budget overruns or not meeting project goals.

Requirements scoping can help keep projects under control by establishing what criteria — such as prioritization — will drive decisions. The process also clearly details what the project will deliver, and perhaps just as importantly, what it won't.

Depending on a project's complexity, goals and project management approaches, there are various ways to manage requirements scoping. Here are three of the most common.

1. Early scoping assumes all scoping is done as part of the project charter or during the scope definition. The approach relies on precise estimations of required resources, budget and time. It discourages scope creep and requirements changes.

The advantage of early scoping is that it facilitates starting project work ahead of time. On the other hand, poorly estimated efforts can translate into budget or schedule overruns, resources bottlenecks or missed project goals. 

Early scoping is recommended for projects where the main focus is on the scope, and on ones with no, or minimal, budget and schedule constraints. For example, early scoping works well on consolidation or integration projects, where the constraints on the scope (budget limitations, for instance) impact objectives.

2. Late scoping is performed after collecting, analyzing and even designing the requirements. At such late stages, efforts estimates are much easier to assess and generally more accurate.

Although late scoping can keep a project within budget and schedule boundaries, this approach has a considerable downside: Efforts spent for out-of-scope requirements are wasted or deferred. Consequently, this leaves less time, budget and resources for addressing in-scope requirements — the ones that matter.

Late scoping is recommended for projects addressing requirements that have similar (and not critical) relevance for the project's outcome — for example, regular maintenance projects.

3. Iterative scoping is a balanced, incremental approach. The entire scope is broken down and prioritized by items that have the highest relevance. These will be addressed in the first scoping round. The rest of the requirements, as well as potential changes or rework, are subject to scoping in subsequent iterations. 

The requirements scoping and the project work advance in a rolling wave approach. Iterative scoping is especially useful for IT and agile projects.

How do you manage requirements scoping on your projects?

Posted by Marian Haus on: January 04, 2013 10:42 AM | Permalink | Comments (1)
ADVERTISEMENTS

"Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats."

- Howard Aiken

ADVERTISEMENT

Sponsors