"Take a number!"
How many times have you heard that from one of your PM buddies? We've always been part of an incredibly busy profession. Now there's a new survey conducted by ProjectManagement.com in partnership with WorkFront,(formerly ATTask) that tells us we are busier than ever. In this survey 55% of Project Managers reported a significant increase in their workload in 2014.
Among other things, the survey shows:
So what do you think this means? Are we just not selecting and integrating our tools well? Do we just have more to do in general? Have you noticed more demand for reporting lately?
Eliciting Requirements... Creatively!
We recently had the honor of speaking with Mary Gorman, Business Analysis Guru and VP of Quality and Delivery at EBG Consulting. Mary will also be a speaker at the PMI Global Congress 2014 - North America, delivering "Creative and Collaborative Business Analysis for High Quality Requirements"
Mary's session is all about creative approaches and techniques for developing requirements - an incredibly useful topic for all of us. Here she offers a taste of what she will deliver in Phoenix. She touches on some really thought-provoking points: keying off of "events", understanding what your stakeholders really "know" and much more.
Q. In your presentation you will be discussing how to make business analysis practices both engaging and collaborative. Are there common elements of the way you approach business analysis that encourage engagement and collaboration?
A: Business analysis is a team sport—to succeed you’ve got to get the right people to work together productively and transparently. By right people I mean stakeholders from the customer, business, and technology realms—a team of product partners. First, you have to identify who these people are, then you have to help them collaborate as partners, which isn’t easy considering they all come from different backgrounds and perspectives. Once they begin to work together, though, the results are powerful.
To help build a team of product partners out of such a diverse group, I often facilitate focused activities that get people up, moving around, and exploring. I design a physical space so that people can conveniently and spontaneously interact as they converse. I encourage visual thinking, inviting them to sketch on posters, walls, or whiteboards, using symbols, colored posts and markers to explore product possibilities. I ask focused questions to stimulate structured conversations among the product partners, helping them to succinctly yet deeply clarify product needs (a.k.a. requirements).
Q. Could you describe your very favorite BA technique and how it’s best done?
A: As a long-time practicing BA and facilitator I have a toolbox of proven, even cherished, techniques. And I continue to seek out new ones. Choosing a favorite is tough! Please allow me to provide two answers.
One of my favorite business analysis techniques is a context diagram—an analysis model that invariably spawns rich conversations. I ask the product partners to create this diagram together, interactively exploring, discussing, and clarifying the product’s scope. (I prefer to keep the drawing low tech, using markers and colored stickies.) First, we draw a circle in the middle to represent the product, which may be a service or a system. Then the product partners add the known external entities, and draw the interfaces to and from the product. As they do this, they typically uncover absent and misunderstood requirements, such as interfaces, missing or extraneous stakeholders, and even key data needs.
My stealth analysis model is the state diagram. I use it selectively, pulling it from my toolbox when a team needs to analyze a product that has an event-rich lifecycle. I start by asking the product owner and subject matter experts to list the key events. For example, when analyzing an insurance claim some events might be submit, register, adjudicate, and pay. We discuss the associated states of the claim, e.g., registered, approved, rejected, pending investigation—the pre- and post-conditions related to the events. Invariably the diagram stimulates conversations among the domain experts. Together, they learn and share rich details about the product’s users, actions, data, and business rules—details that might otherwise have been overlooked or misunderstood.
One of the beautiful things about the appropriate use of these tools is that the participants do not need to be experts in the models themselves—their form, format, and semantics—but only in the content. The creation process itself is about mutual exploring, questioning, and learning. These and other analysis models help build powerful and trusting partnerships among stakeholders.
Q. You talk about discovering the right requirements at the right time. Could you tell us a bit more about that and perhaps offer an example?
A: Let me start with a story. In a recent engagement I was asked to help a team that had spent considerable time laboring over very detailed wireframes. What was wrong? After a brief assessment, the team quickly realized it had no grasp of the underlying business rules, was confused about the source of the data, and had at least three unsupported users. The team’s deep dive into the user interface had been too narrowly focused! I helped them readjust and take a holistic approach, exploring the full range of product needs using the 7 Product Dimensions to incorporate both functional and nonfunctional requirements.
As the team began to focus on the right requirements, we worked together to understand how to explore them at a consistent level of detail. As I noted the team’s UI work was very specific. It needed to be supported and validated with detailed business rules and data on an ongoing basis.
By the same token, teams need to discover and define detailed requirements at the right time—just shortly before they are developed—so they are “fresh.” It’s risky to invest in detailed requirements well before development begins—because as business and technology needs change over time, so must the requirements.
Really, it’s all about value! The right requirements are those that are highly valued by the customer and business, at that particular time.
Q. What do you see as key strengths in the new PMI-PBASM certification? Where should applicants focus their efforts when studying for this credential?
A: PMI’s Professional in Business Analysis (PMI-PBASM) Exam content outline offers a practical overview to business analysis. (Disclosure: I served on the task force that created the Examination Content Outline.) By reviewing the five domains (along with the 28 supporting tasks) anyone can quickly grasp the key aspects used to discover and manage requirements. Say you are a project manager assigned to a new project. You and the business analyst can easily review the domains and tasks to better assess what work needs to be done and consider the level of effort needed.
Well before studying for the examination, it is wise to calculate whether you meet the certification requirement of at least 7,500 hours of business analysis experience. Do a thoughtful and honest self-assessment. Review the five domains and see if you have balanced experience in all. Consider your level of expertise in the 40 skills and knowledge topics listed in the Examination Content Outline. What are your strengths? Where do you need to learn and grow? Search out stretch assignments to help you grow in those areas. And most importantly, remember doing business analysis work is the best preparation for passing the exam!
We recently had the honor of speaking with Ori Schibi, author of the book “Managing Stakeholder Expectations for Project Success” Ori will also be a speaker at the PMI Global Congress 2014 - North America, delivering "The Role of the Business Analyst in Managing Stakeholder Expectations " So you kind of get the feeling that he knows what to expect from stakeholders.
Although most of Ori's answers imply an increase in the scope of the BA role and what appears to be additional work volume - he believes deeply that enhancing the collaboration between the PM and the BA will allow both roles to achieve more effective results with improved efficiency – resulting in less work for each overall.
Q1. How important is the role of the BA in managing stakeholder expectations? Are there ways of increasing or decreasing that importance? (Perhaps by making their power/lack of power to alter scope clear?)
The role of the BA in managing stakeholder expectations is important and can be substantial, even though this aspect of the BA’s role is often overlooked. In fact, there is a strong need for an increase in the BA’s role in managing expectations. There are multiple areas that are inherent to the BA’s role and the knowledge that the BA brings to the table that can provide significant value to the effort of managing stakeholder expectations. The areas of potential contribution span all throughout the project:
1. Take part in performing project complexity and readiness assessments to identify early areas of deficiency or concern
2. Take a more active role in providing information for the Project Charter, utilizing the BA’s knowledge of the business case and other early project-related due diligence activities
3. Establish clear boundaries with the PM on who does what (in the areas of risk, quality, transitioning requirements and scope management, communication, issue management and reporting)
4. Provide the PM with a “package” of background documentation, access information, and existing resources that are applicable to the project
5. Take an active role in managing issues and assumptions
6. Establish guidelines for prioritization and urgency (cross-project and within the project)
7. Jointly (with the PM) define project success criteria and trade-offs that factor in both project and business objectives
8. Help the PM articulate the cost-benefit and impact of actions, decisions or delays
9. Jointly build a set of Health Measures that serve as early indicators to stakeholders of trends and warning signs before performance issues surface
Q2. What are the top 3 ways Project Managers could work with stakeholders to improve stakeholder communications?
1. Focus (i.e. invest time and energy) in building trust, developing a rapport and establishing healthy working relationships with at least a representation of the key stakeholders (partially by utilizing the BA’s familiarity and existing relationships with stakeholders)
2. Establish a Team Contract that outlines a set of ground rules to set expectations and serve as a code of conduct for communication within the team and with external stakeholders. This Team Contract should address three areas:
a. General communication
b. Emails and messaging
c. Meetings and teleconferences
3. Create a Delegation and Escalation system that will free up some of the PM’s time to handle “strategic” aspects of the project (e.g. resource management, cross-project dependencies and business risks), specifically:
a. An “internal” system (within the project team) of delegation and areas of ownership that builds a system of support for BAs and team members to handle an agreed upon set of ongoing “mechanical” responsibilities of the project (e.g. schedule management and certain aspects of reporting)
b. A combined internal and external set of clear escalation procedures for risks, reporting, issues and controls to reduce “noise” in the system.
Q3. What role does the BA play in managing risk? Are they more able to identify risks than the Project Manager?
The BA has the organizational and product knowledge, as well as exposure to project related processes and activities that enables the BA to make an even greater contribution to managing risk than even the PM.
The BA’s involvement in risk management should focus on three categories, depending on the project’s needs and on the BA’s level of experience:
a. Requirements management (i.e. the process) related risks – with the central role the BA plays in the requirements process, he/she needs to (and often does) lead the effort of managing risks related to and around the requirements process, and incorporate all remaining risks into the overall project risks considerations. These are mainly risks that may impact the project success criteria.
b. Requirements and scope (i.e. the product) related risks – the BA needs to capture and introduce into the project risk management process all of the risks related to the actual requirements; i.e. risks that may impact the ability of the project to deliver product and project success. Since the PM has no clear context and visibility into the requirements, the BA is perfectly suited for integrating the requirements related risks into the project.
2. Project risks – beyond the familiarity with the product, the BA is also closely involved with project-related processes, team coherence and performance, roles and responsibilities, and has visibility of other issues, assumptions and constraints. Having this additional set of eyes involved in and interacting with the day-to-day project work can be handy in providing the PM with alerts and help the process of managing by exception.
3. Context for business/operational risk – with the PM typically focusing on project risks (surrounding the project success criteria), many of the PM’s decisions may be “good for the project”, yet at times be misaligned with business objectives and/or existing operational issues, or ones that may be triggered by project decisions (e.g. reducing the testing time to achieve schedule milestones, which may increase the risk for defects and other post implementation issues). In this case the BA can serve as the “voice of reason”, resulting in better likelihood to address both project and business related risks and considerations.
Q4. What role does the BA play in managing quality? How is that best clarified in the requirements they produce (both written and verbally communicated)?
The BA should, along with the PM, own quality. The BA is the most applicable person to lead the effort to pursue quality and in turn ensure that the PM maintains a focus on quality. Quality is the key to achieve a combination of product quality, project success and customer satisfaction – and the BA has the most applicable knowledge of these areas.
The way to achieve quality is by integrating all relevant considerations into the project decision making process. Working with the PM, the BA should provide an impact assessment of actions and decision on the product and on any downstream areas – with a focus on business value and post project impact.
More specifically, the BA should lead the enhancement of the quality assurance role (e.g. audits, reviews, process analysis), lead the way in producing project health measure indications, and incorporate cost of quality analysis to ensure impact is expressed in terms and values that resonate with stakeholder needs.
The BA plays an important role in producing quality through the requirements. With over 40% of project defects traced back to the requirements, owning the quality starts with producing requirements that are SMART-CUT (Specific, Measurable, Attainable, Realistic and Time-bound; Clear/Complete, Unambiguous and Traceable). Applying the notion that “quality needs to be designed into the product and not inspected into it” makes it the BA’s role to take quality seriously from day one and ensure that no requirement makes it into the project if it’s not ready to go. Further, it is the BA’s responsibility to ensure that the requirements “hand-off” is done properly so that each requirement is appropriately represented in the project scope, as well as in subsequent planning.
Conceptually, the BA should deal with, if not own, all of the “invisible” aspects of quality, i.e. those parts of the quality iceberg that is under water. These “invisible” aspects are the hidden costs organizations incur as a result of poor quality; these costs are difficult to track and account for, as they are spread over time, beyond the project end date, and over multiple cost centres – depending on the areas impacted.
Q5. Could you tell us a bit about your book? Perhaps give us three things that our members might find most useful about it?
1. “Managing Stakeholder Expectations for Project Success”is a pioneer in providing an integrated approach to managing stakeholder expectations, by offering a broad context for the area of stakeholder engagement. The book reviews and considers everything that the PM needs to do in order to effectively manage stakeholder expectations; and ultimately deliver project success. With that, the book introduces a comprehensive Team Contract that allows the PM to “own” project communication and effectively addresses common issues that often plague projects’ and teams’ performance in a meaningful and constructive way.
2. The book focuses on what the PM needs to do and to focus on and how the PM should to utilize his/her time to maximize the value produced by working smarter, not harder. It clearly articulates common challenges and problems and provides simple and straight forward approaches to address them, establish environments that foster collaboration, overcome barriers and continuously keep an eye on project success criteria and their alignment to business objectives.
3. The book is intended not only for PMs, but also for BAs (to enhance the BA’s ability to add value to stakeholder expectations management) and for Project Sponsors (to clarify the mandate they need to provide PMs so the job gets done). In addition to being relevant for the three leading non-technical roles in a project, the book is also a first to introduce a detailed breakdown of what project integration entails, along with full consideration and impact of dependencies and project trade-offs. Additional concepts that contribute to the reader’s ability to apply critical thinking include time management, and a mechanism to determine urgency and prioritization.
My upcoming book (no title yet) deals with how to enhance and streamline the relationship, touchpoints and collaboration between the PM and the BA and is due to be published in the Fall of 2015.
Ori Schibi (MBA, PMP, PRINCE2 Practitioner), is a visionary leader, communicator, connector, and devoted husband and father. With 24 years’ experience, he offers practical and unique ways to effectively manage projects and people. Ori is the President of PM Konnectors (www.pmkonnectors.com, a Toronto, Canada based Consulting firm specializing in program/project management / recovery, PMOs, cost of quality measurements, process streamlining and improvement, PM/BA skills assessments and communication management. Ori is the author of the book “Managing Stakeholder Expectations for Project Success” (J. Ross, 2013; www.ManagingStakeholderExpectations.com).
8 More Templates to Save You Time
Categories: New Templates
Happy August & thank you for being Members of the ProjectManagement.com community!
This month, we are including 2 NEW TEMPLATES and six from our vast collection!
Don't forget you also have access to everything in the entire PREMIUM TEMPLATE library! We hope these make your life a bit easier – helping us fulfill our mission of making YOU more successful.
The following premium templates, two newly available as of this month, are available to all premium members and to ALL members through Wednesday, August 27th.
What's The WORST Thing a PM Can Do?
I recently posed this question on Quora, knowing that there are a thousand potential answers - all of them probably valid when you spin them the right way. However everyone has a favorite which is born out of their own personal experience, probably some tragic PM circumstance that produced a "worst case" result.
So why bother with trying to identify each individual's "PM pet peeve"? Assuming each strong opinion is the result of some tragedy - this gives you a list of really important pitfalls to avoid - each of them THE most important in someone's eyes.
Here are a few responses from others. If you have a moment, please add your experience to the comment string...
LETTING PROBLEMS FESTER
COMMUNICATION AND RECORD-KEEPING
FAILING TO PLAN
LACK OF FORESIGHT
FAILING TO LEAD