Tag: Planning

Less Is More

Written by Marcos Ferrer on December 10, 2013. Posted in Articles.

Last month I put my foot in my mouth in a feeble attempt at mocking the thousands of pundits who have the “answer for ObamaCare”. I may have succeeded by being a bigger jerk than any of them – sigh 

This month I apologize by shutting my mouth with the following model. The model shows BABOK™ Enterprise Analysis and its immediate inputs and outputs.

AND, thanks to Dave Offenkrantz, PMP, who cared enough in a ridiculous situation to give me this month’s title and the wisdom behind it.

Nuff said!

Click image to view original size

Don’t forget to leave you comments below.

Thinking Like a Business Analyst

Written by Steve Blais on November 26, 2013. Posted in Articles. 1 Comment on Thinking Like a Business Analyst

I was flattered recently during a meeting about a proposed merger when I was waxing eloquent, or perhaps ineloquent, about a review of the business processes and seeing how the business processes matched in each organization. I was suggesting a ‘pick of the litter’ approach. One of the directors at the meeting said that I was “thinking like a business analyst”. I doubt he was thinking about requirements or projects. The business analysts he probably was referring to were those who analyzed the businesses of organizations the company was contemplating merging with or acquiring. He may also have been accusing me of some negative attribute he associated with business analysts, but I took it as a complement, nonetheless. Regardless, it got me to thinking about thinking.

Thinking Fluently

The thing is that we don’t think in words, we think in pictures, images, concepts, and so forth and then translate them into words in order to communicate them. Perhaps fluency, or “thinking like…” is a matter of seeing and understanding the pictures or concepts instead of or in addition to the words. For example when you learn a second language you spend lots of time translating the words. To understand a word in the second language, you translate it first into a corresponding word in your native language which produces an image in your mind. An English speaker learning Spanish would translate “el vaso de agua sobre la mesa” into “the glass of water on the table” and then see the image of the glass on the table in her mind. A Spanish speaker would see the image in her mind immediately. When you are fluent in the second language, you are able to do the same as the native speaker: see the image without exchanging the words in your frontal cortex. Of course each of us has a different image in our heads of what a glass of water on the table looks like, but that’s fodder for another article later.

So we might conclude that if we are “thinking like” some role, or profession that we find ourselves fluent in that role, or profession, or in other words, we see the concepts and images instead of just the words. There may be other phrases or descriptions for the same thing, such as someone “getting it”, whatever “it” is, or to borrow a phrase from the current discussions of agile, “you don’t do agile, you are agile”.

Thinking like…

I think we all have roles or positions or times in our life when we can say we were or are fluent in something, other than a language. For example, at times in my life, I have felt myself fluent in several roles.

In my early years I thought like a programmer. When presented a problem. I could see the code that would be written that would solve that problem. Unfortunately, I probably suffered from what Gerry Weinberg calls the “No Problem Syndrome” in which case I was probably mentally seeing a solution in code before the problem was fully explained. Too many jumping to solutions in that way is another definition of “thinking like a programmer”.

There was also a time that I felt as though I thought like a system analyst or designer. I could see the software programs interconnecting, accessing data, and even the hardware devices on which they would reside. As an analyst I could see the pieces of a larger problem, sometimes with an inability to see the larger problem itself. As a data modeler, for example, I would think in terms of entities, relationships, foreign and primary keys, even when conducting the initial interviews with the users and business stakeholders. This, as you can imagine, resulted in some rather interesting miscommunications during the elicitation phase.

On the other hand, I was never much good at thinking like a project manager. While I had my successes in project management, there were those of my peers who could see a Gantt chart in their heads when presented with the project charter. They could mentally break down the scope into a work breakdown structure and could see the precedence network in their heads with all resources arranged and delegated amongst the tasks. I needed to go through the routine of decomposing and organizing the project with the team. I tended to think technically rather than managerially. It wasn’t ‘instinctive’ to me until I had spent many years managing, at least not as instinctive as writing code or designing systems.

Not a success guarantee, but certainly an indicator

Fluency, or “thinking like..”, is not a guarantee of success in any given profession or role. In other words, you can certainly be a success in a given role without becoming so invested in that role that your thinking is consumed by it. There is certainly evidence and cognitive behavior studies that indicate that we have predilections for fluency in certain areas. Some people have a natural ability to learn languages and the intonations and inflections that make their recitation in that language seem natural, even to a native speaker. Others struggle just to learn enough vocabulary to understand, much less speak. Similarly, some people will find it much easier to be fluent in a programming language than others. However, fluent or not, a person may be a highly successful programmer, designer, project manager, speaker of a second language, or business analyst without necessarily being fluent.

On the other hand, there is also evidence that indicates with focus, attention, practice, and intent, one can master a role, and become fluent in it, even without a predilection toward it. In the book outliers, Malcolm Gladwell suggests that one can become an expert, be fully fluent, in a role or profession by practicing that role or profession for 10,000 hours.

Regardless of whether you have a penchant for it or not or whether you are fluent in business analysis or not, you will be more successful as a business analyst when you think as a business analyst. So what does it mean to ‘think like a business analyst’?

Thinking like a business analyst

The problem with ‘thinking like a business analyst’ is that the role of business analyst is so vague. A programmer programs, she writes code that makes computers do things. A system analyst or designer analyzes problems and creates computer-based systems to solve those problems. What is the specific activity that the business analyst thinks about?

Requirements? Can you imagine thinking about everything in terms of requirements, as in “It is dinner time, what are my requirements for dinner?”
Documentation? Yes, the business analyst seems to do a lot of documentation such that sometimes his entire role seems to be about documentation, but thinking in documentation, as in “let me write down what I am going to wear to work today” doesn’t seem to be applicable.
Liaison or translator between the business and IT? Your thinking might run like this: “let me explain to you what is going on with this television show, dear”. No, that doesn’t quite get it either.

Since all business analysts regardless of assignment or interpretation of the position or role are problem solvers, (the business analyst’s mission: Business, the final frontier. This is the mission of the business analyst: to go identify business problems, to seek out new solutions, to boldly go where no business analyst has gone before. [1]) perhaps thinking like a business analyst is thinking as a problem solver. Sherlock Holmes comes to mind as an example. Mr. Spock is another.

We are all born with the capacity to solve problems. Many of us let that capacity atrophy as we get older for a variety of reasons, mostly cultural and social. After all, Holmes and Spock are not the most lovable of characters. If you look at problem solving thinking, you see a number of different modes of thinking that may go into solving problems.

Critical thinking is a form of reasoning that challenges thinking and beliefs to determine what is true, partially true, or false. For example, a business analyst thinking critically would question the problem statement to make sure that it is the real problem statement and not the description of a symptom before proceeding with the analysis. Critical thinking underlies the other business analyst problem solving thinking modes. Sherlock Holmes is an example of a critical thinker, constantly challenging LeStrade’s and others’ assumptions of guilt or innocence as not being based on facts.

System thinking is the process of viewing problems as parts of whole systems rather than individual occurrences. The business analyst needs to view the organization and its business processes as a system or systems within systems to truly understand the impacts of the changes to the organization that the business analyst is bringing about. There have been a number of discussions on LinkedIn business analyst discussion groups lately about the application of system thinking to business analysis masterfully led by Duane Banks and Julian Sammy.

Strategic thinking as applied by an individual involves the generation and application of insights and opportunities that extend beyond the present timeframe. While system thinking provides the business analyst the larger view in terms of breadth, depth and context, strategic thinking provides the business analyst a larger view in terms of time. While strategic thinking is not usually associated with the business analyst who typically works on projects which are tactical in nature, the business analyst, being in the center of business and IT is usually in a prime position to understand the strategic implications of the projects and products on the organization.

Analytical thinking is essential to problem solving and goes hand in hand with critical thinking. Critical thinking and analytical thinking are sometimes considered synonymous. Critical thinking is specifically focused on thinking while analytical thinking is focused on everything else. Since it is often difficult to see the complete problem or the entire situation in which the problem exists given the complexities of business and technology today, the business analyst breaks the larger picture into smaller more manageable images to make examination and understanding easier. Again, Sherlock Holmes broke crime scenes down to pieces of evidence that, when put all together, assembled a complete picture of the crime and the perpetrator. This reassembly of the evidence or the pieces back into a complete whole to determine the ‘crime’ is what allows business analysts to be both system thinkers and analytical thinkers successfully. The two modes of thinking are not diametrically opposed or mutually exclusive.

Visual thinking is perhaps the only mode that might require a bit of predilection in that some people are more visual than others. But this thinking mode brings us all the way back to the initial premise that we don’t think in words, but in images and concepts: visions. To the degree that we as business analysts can visualize the problem and solution and describe that vision or render the vision into graphical form is the degree that we will be understood in our efforts to communicate.

Now that I think about it…

Thinking like a business analyst might be simply thinking first:

Thinking before reacting,
Questioning before accepting,
Verifying before assuming,
Understanding before judging,
Viewing the whole process before focusing in on the detail issue,
Analyzing before concluding,
Visualizing before writing.

While we as business analysts value the activities on the right hand side we value the activities on the left side more (to paraphrase the Agile Manifesto). Thinking like a business analyst may simply be a matter of reasoning about problems, visualizing solutions, and asking more questions.

Don’t forget to leave your comments below.

Effective Requirements Planning

Written by Kathleen O'Brien on November 12, 2013. Posted in Articles.

Why do I need to plan?

When I think of requirements, a picture of Mr. Potato Head comes to mind. There are a bunch of pieces and an infinite number of ways to put the pieces together. You need an approach for building the requirements specification.

This same principle applies to requirement development. If you don’t plan before you jump into the requirements development, you may experience the following consequences:

Ineffective BA techniques
Inability to respond to project evolution in an organized manner
Missed timelines
Forgotten sections of requirements
Lack of alignment between the capacity of the team and the schedule

As Dwight D. Eisenhower said “In preparing for battle, I have always found that plans are useless but planning is indispensable”. Additionally, a requirements effort is a journey that you as the BA are leading a team along. If you don’t have a solid plan how can you communicate a clear vision to your team and gain their commitment?

In the BABOK, “Plan Business Analysis Approach” is the 1st task in the 1st knowledge area “Business Analysis Planning and Monitoring”. This highlighting that this task is the place to start when developing requirements. But so often we have no time to plan upfront. Our PM comes to us and says I need the requirements done in 2 weeks. As good team players we get them done but then pay the price by constantly changing the requirements since they were not done right. We all know the cost of poor requirements to IT organizations. Per the Standish Group Reports1, only 32% of IT projects are successful and 20% of the features / functions delivered are used regularly. Multiple studies have traced these IT failures to poor requirements definition.

Therefore, I am proposing we as BAs need to embrace the need to plan and to sell this to our PMs. I hope this article give you the background you need to develop a solid Requirements Approach and the ammunition to sell this to your PM.

A Requirements Approach allows you as a BA to:

Select the best methodologies and techniques for requirements development based on the needs of the project and stakeholders
Develop consistent requirements
Gain commitments from all stakeholders to provide necessary time and input
Respond to project evolution in an organized manner
Clearly communicate BA commitments and establish a BA contract with IT and business stakeholders

But it is not all about the BA benefiting! Developing a solid Requirements Approach benefits the entire team. For Project Manager, the Requirements Approach can be the basis for developing detailed, accurate project plans. For Business Partners, the Requirements Approach provides visibility which sets clear expectations and fosters a collaborative environment. For the QA professionals on the team, the Requirements Approach provides insight into the requirement deliverables so the testing efforts can be proactively planned at the start of the project.

The Lead Business Analyst develops the approach and collaborated with the other BAs on the project, the PM and the business partners to refine the approach so it meets everyone’s needs and incorporates the team’s diverse perspectives. The Requirements Approach should be an official project deliverable but does not have to be a 100 page document. A short document or a PowerPoint is sufficient. The goal is to think through the approach and get team buy-in, therefore right-size the deliverable to meet this goal.

How do I create a Requirements Approach?

A Requirements Approach is a roadmap for the developing requirements for a project. The Roadmap should cover all phases of requirements development:

Planning – Develop a plan for gathering and communicating requirements.
Eliciting and Validating – Extract information to prepare to document the requirements.
Documenting – Collate, author, and publish requirements to stakeholders.
Approving – Secure acceptance of the requirements from the stakeholders.

The following components should be defined for the Planning phase in the Requirements Approach:

Scope – Clearly define what is in scope for the requirements development effort and enumerate out of scope items. Note, this is not the scope of the project which should be clearly outlined in a different document.
Assumptions, Dependencies and Risks – List all things that effect or constrain the requirements development effort.
Standards – Define the industry, company and divisional standards guiding this effort.
Requirements Development Team – Define roles (both IT and business) and individuals that fill these roles.
Requirements Development Communication Plan – Define communications to be sent regarding requirements development to keep key stakeholders informed on progress. The key stakeholders are those defined during stakeholder analysis.
Requirements Development Project Plan – Key factors that affect the requirements development project plan such as BA resource constraints along with high level timelines and resources for the requirements development effort. A link to the requirements development project plan is also included.
Requirements Change Management – Define how changes to the requirements will be handled.
Methodology – This is the core of the requirements approach since it clearly defines how the requirements development effort will be structured.

Let’s discuss the methodology component in more detail. In the methodology component, the following should be defined:

SDLC methodology (Agile, Waterfall, Iterative, etc.)
Types of requirements to be developed (Business, System, Analytics, Integration, etc.)
Steps for defining each type of requirement
Tools, techniques and details for each step

To help make this more real, here is an example of a Methodology section from a real life project:

The Planning section is the bulk of the Requirements Approach. The table below shows the components for the other 3 phases:

That covers the components of a Requirements Approach. Just remember, this is not a once and done artifact! Get your initial approach defined but be ready to continuously refine as the needs of the project and team evolve.

Finally, use your tools to enforce your requirements approach:

To make getting started easier, I created a template.

Good luck with planning a successful requirements development effort.

Don’t forget to leave your comments below.

Sources:
1. Chaos Study 2009 – www1.standishgroup.com/index.php
2. BABOK v2.0 2009 – http://www.iiba.org/BABOK-Guide.aspx

Resources for Related Topics:
– Stakeholder Analysis – BABOK v2.0 Section 2.2
– Communication Plan – BABOK v2.0 Section 2.4
– Work Breakdown Structure – BABOK v2.0 Section 2.3.4.4

The Bermuda Triangle for Projects

Written by Ieuan Wickham on November 5, 2013. Posted in Articles.

We all run afoul of this from time to time – it’s known as the Project Management Triangle or the Iron Triangle. It encapsulates the tension between schedule, cost and scope that occurs on any project, and it appears in a number of forms. Over time, as the Wikipedia article demonstrates, people have explored how it’s not quite that simple. In constructing a house, for instance, you can still achieve the essence of the scope of the project (e.g. all the rooms) in fixed time and cost by sacrificing quality (e.g. a formica bench instead of granite, or cheaper carpet).

It is also a critical factor in how we as Business Analysts prioritise business, stakeholder, or solution requirements. For each requirement it should be possible, if you are so inclined, to measure time and risk and cost and the value delivered by the scope of the requirement. In practice, prioritisation is typically done by a subjective stakeholder agreement session.

Understanding What’s Wrong

The Iron Triangle reaches its nadir in the phrase: ‘Fast, cheap, good – pick two.’ I have two issues with this sentence.

The first issue I have is that it encourages the idea that it is always possible to actually complete a large project on time and on budget. (That’s not what it says, but it is how it’s interpreted.) Sadly, for most Information Systems (IS) projects this is more due to good fortune than good judgement or hard work. The second issue is that ‘good’ is interpreted as referring to quality rather than scope. A while back I worked on a project where the stated priorities were time, then cost, then quality – “but we’re not sacrificing quality at all”.

Here’s why I think having an Iron Triangle of time, cost, and quality is a bad idea on an IS project. Scope in this context is implicitly fixed, even if it’s not fully understood. But when we sacrifice quality, what we’re actually sacrificing is uncontrolled scope. This is because quality usually degrades unevenly across the scope of the project, although it may degrade more in specific areas. If a piece of software has poor quality, it means it doesn’t do the job that’s being asked of it to the standard required by the client. I don’t mean that the solution must instead be perfect; rather, that it should meet the agreed and accepted quality targets. If it doesn’t then the client will not accept the solution, either actively by rejecting it or passively by not using it.

For the example below, imagine our scope as a list of 100 requirements, grouped so that requirements near to each other are part of the same scope area. As the project proceeds, analysis uncovers 10 additional requirements, which we insert in their appropriate places in the list. This causes the scope to expand.

Figure 1- time, cost and quality.

Figure 1 demonstrates what happens if we sacrifice quality. At some point (usually late) during the project we find out that due to poor quality, the requirements will be incompletely met across all requirement groups. The solution doesn’t work, and it’s not going to work within our ‘hard’ constraints of time and cost. To deliver a complete solution we now have to choose whether to:

allow an increase to time and cost, i.e. overrun the project, in the name of delivering the expected and agreed scope;
make scope cuts to meet the budget by stopping work on some of the groups of requirements, against the backdrop of an expectation that the full scope will be delivered;
or, more likely, both.

What We Can Do Better

Figure 2 – time, cost and scope

In contrast, Figure 2 shows the result of sacrificing scope. As analysis proceeds we determine early that we won’t meet the budget, because our understanding of the size of the scope has increased. We reduce the scope in agreed areas as early as we can. This allows us to manage the savings that we need to continue to provide the best value, instead of being driven by the quality of the delivered functional areas. It also allows us to set expectations early about what scope will be delivered, and what workarounds or alternative solutions might need to be put in place.

When we get the opportunity to work with stakeholders to determine how we define project success, project sliders can be useful. I prefer to use sliders in such a way that no two sliders can be on the same setting. This means you need as many settings as you have sliders, but they prevent someone from setting time, cost and quality as 5 and everything else as 0, for instance. This isn’t a problem that we fix with tools, it’s about education and setting expectations. And sometimes we’re just not in a position to influence these attitudes.

When we’re working with stakeholders to prioritise requirements, we need to encourage them to think clearly about what their priorities are, and the implications of setting those priorities given the funding and schedule. We also need to make sure that the stakeholders can trace the requirements to their relevant benefits and understand the relevant costs, benefits, risks, compliance aspects, or whatever factors they have agreed to be used for prioritisation.

For example, using MoSCoW priorities:

If it’s a Must-Have, then if we can’t find a solution, we need to reconsider the project viability. (Are you sure it’s a Must-Have? Does the business value of the requirement justify this?)
If it’s a Should-Have, we’ll do it if we have time and budget left over. (What are the relative priorities of the Should-Haves?)
If it’s a Could-Have, then we’ll only do it if it’s effectively free.

We need to do this whenever we’re deciding which requirements to proceed to the next stage with. For a Scrum project, this might be at each sprint. For an iterative project, this might be at the end of the stakeholder requirements analysis and the end of the solution requirements analysis for each iteration.

If instead the stakeholders persist in talking about time, cost and quality, it encourages them to think of scope as being fixed and the ‘everything’s a must-have’ mentality. It makes it harder to admit that they need to make the tough call early, and either increase schedule or cost, or decrease the scope. When they finally need to make the call, it’s more expensive and they have fewer choices.

That’s when the stakeholders need to admit that they didn’t have a priority of time, cost and then quality. What they actually needed was the ability to make transparent and informed choices about changes to scope, cost, and time. We as Business Analysts contribute to this by performing sufficient requirements analysis to identify those prioritisation factors, and by encouraging stakeholders to review their prioritisation at the right times.

Don’t forget to leave your comments below.

What’s Down with Agile Documentation?

Written by Ellen Gottesdiener on September 10, 2013. Posted in Articles.

Recently we worked with an Agile team that was building an FDA-regulated medical device. Some team members were worried about how to produce the required verification and validation documents. “What do we do?” they asked us. “We’re not supposed to do documentation in Agile.”

That’s a myth. In Agile, the question isn’t whether to document. It’s what kind of documentation to create, and when. Like everything else in Agile, those decisions are based on your assessment of value—in this case, the value of the documentation. More documentation is not necessarily better. In fact, the volume of product documentation often is inversely related to its value.

Figure 1: Potential Nonlinear Relationship between Documentation’s Volume and Value

Image Source: Discover to Deliver: Agile Product Planning and Analysis, Gottesdiener and Gorman, 2012

Process Versus Product Documentation

You essentially have two types of documentation: process and product documentation. In either case, we urge teams to focus on the documentation’s consumers and look closely at their usage needs. Look at the documentation from the consumer’s perspective, and explore her usability needs to determine the minimum useful and usable documentation.

Process documentation describes the work-in-progress or handover information the stakeholders produce as they discover and deliver the product—the software application, system, or device containing software. Process documentation has less value for a co-located, domain-savvy team than for a team working in a distributed mode in different time zones and with varying degrees of domain expertise. On the other hand, even a co-located team may need process documentation if it’s building a regulated product and requires evidence of product verification, as in our client’s case.

Product documentation, which conveys information about the product, is an asset that tends to be valuable because it’s used to sell, service, and use the product. Consider that the consumer of your product documentation might be a validation analyst from a regulatory body, a product end user, an installer, a help desk technician, a field staffer, a maintenance programmer, and so on.

For our medical device client, the product documentation included scripts for a demo used to conduct validated learning to test the product idea itself. We took the perspective of the people going on-site to conduct the demos, and as a result we created a booklet in a slim, tabular format with abbreviated feature descriptions and demo steps. Not only was this booklet “just enough” to document the product, but also it was fast to produce. As a bonus, the delivery team found the format useful for onboarding new team members.

On Your Mark…

Teams, including the product owners, need to decide when to produce documentation. There are the two meta-patterns: build it incrementally in small bits as you build the software (and when you have the greatest knowledge for creating the documentation), or defer until prior to release (batching documentation as larger set, created all at once).

When the requirements are fairly well known, documenting early and often makes sense. On the other hand, our medical device client was essentially a start-up. The potentially lifesaving devices were being used experimentally with patients in the hospital, and the requirements were changing as the product itself was being tested. This meant that it would have been wasteful to document what the team was delivering at each iteration. They agreed to wait to document prior to each release throughout the experimental usage of the product (this is roughly equivalent to what a lean start-up calls “validated learning”). For this team, it made sense to defer documentation.

A good practice is to produce documentation as part of the acceptance criteria for completing a slice of the product, whether it’s a story, feature, or minimum marketable feature—whatever anchor you use to describe the requirements you’re delivering. When you make the necessary and sufficient documentation a part of the acceptance criteria, you’re gaining value for little added effort.

Sliding Along the Documentation Levers

Consider documentation formality and precision and the volatility of your requirements. Do you need documentation that conforms to a predefined format, sign-off, and so on? Will informal documentation good enough? How precise must the documentation be? Who will be consuming the documentation, and to what end? And as with our medical team, documenting too soon would have been wasteful because of the volatility of the requirements, and yet when it was produced, it needed to be precise and formal.

There is no one size fits all. As shown in Figure 2, different product and project situations influence how you will adapt your documentation plans.

Figure 2: Adapting Your Document for Different Products

Image Source: Discover to Deliver: Agile Product Planning and Analysis, Gottesdiener and Gorman, 2012

The Low Down on Documentation

Documentation boils down to knowledge transfer. Where possible, document in chunks, and deliver just enough to serve the needs of the specific consumer of the documentation. In that way, you maximize the value you create for the effort you invest.

Don’t forget to leave your comments below.

Reference:
Gottesdiener, Ellen and Mary Gorman. Discover to Deliver: Agile Product Planning and Analysis. EBG Consulting, Inc., 2012.

About the Authors:

Ellen Gottesdiener, Founder and Principal of EBG Consulting, is a leader in the collaborative convergence of requirements + product management + project management. Ellen coaches individuals and teams and facilitates discovery and planning workshops. A Certified Professional Facilitator and a Certified Scrum Master, she writes widely and keynotes and presents worldwide. In addition to co-authoring Discover to Deliver: Agile Product Planning and Analysis, Ellen is author of Requirements by Collaboration and The Software Requirements Memory Jogger.

Mary Gorman, a leader in business analysis and requirements, is Vice President of Quality & Delivery at EBG Consulting. Mary coaches product teams and facilitates discovery workshops, and she trains stakeholders in collaborative practices. She speaks and writes on Agile, business analysis, and project management. A Certified Business Analysis Professional™ and Certified Scrum Master, Mary helped develop the IIBA® Business Analysis Body of Knowledge® and certification exam, and the PMI® business analysis role delineation. Mary is co-author of Discover to Deliver: Agile Product Planning and Analysis.