Tag: Risk

Question Everything About your Business – 7 candid questions that need to be asked

Written by Richard Lannon on September 8, 2014. Posted in Articles. 1 Comment on Question Everything About your Business – 7 candid questions that need to be asked

Good questions are the key to successful planning and decision making. Throughout the business planning process we must consider strategic questions to help us understand the current situation, focus areas and our vision for the future. Strategic planning is an intensive process and should be a team effort – it should not be done in isolation.

A good place to start in the planning process is to focus on ‘what’ questions. What questions are extremely powerful tools for thinking about your business / personal strategy, goals and objectives. The key is to know which questions to ask and to be willing to take a candid look at your business.

Here are seven candid “what” questions that every business leader should ask:

What are the overall strengths and weaknesses of your business?

Strengths and weaknesses exist in all organizations and should include considerations for people, resources, culture, work processes, tools, supply chain, financial situation, etc. The list goes on and on. The important thing here is to start the process by first looking at your organization and its resources.

What are the overall opportunities and threats to your business?

Focus here on your external world, the things you cannot control but must be aware of. Some items could include a market shift, retirement and succession, competitive movement and changes, the global business climate (local, national or international), obstacles or climate and weather effects. We often miss the opportunity to do environmental scanning. Look outside your office to truly understand the opportunities and threats to your organization.

What political, economic, social and technological conditions impact your business?

What’s happening in your local business scene (economics)? Is there a product or service that people want or need to buy? Is technology impacting your team and their need for training? What important social change will impact the business? Are you developing leaders for tomorrow? Every answer should lead to another question. Dig deep, exhaust yourself and find people to help you through the process.

What do you want to achieve, protect, avoid and eliminate?

This question contains all the elements of risk planning. There are always things we want to achieve, protect, avoid and eliminate on a personal, team or organizational basis. What are they? Identify as many as possible and make a list. Examples vary but could include increased sales, keeping an established portfolio, avoiding trouble or accidents, establishing an employee health program or helping people drop a few pounds. The point here is that whatever is identified must be relevant to your business and its challenges.

What are the key challenges you face today, tomorrow and in the distant future?

We’re in an era where we must be predictive and adaptive business leaders and professionals. Strategic planning is about timeframes with past, present and future considerations. Establish what your work world should look like with timeframes. Planning used to focus on 3 to 5 year cycles. That has changed. Now we must keep our eye on short-term road trips with long term implications.

Where are we and how did we get here?

This question is a pure honesty question. Success and failures in every business should be reviewed periodically. It is used to establish your present situation and to help you accept complete responsibility and accountability for it. No blame-storming allowed. Outside forces might have contributed, but at some point decisions were made to set your direction. As a business leader, you were either active or reactive and there were consequences. Capture it, leverage it and be prepared to let it go.

What key initiatives are going to be placed on the strategic agenda of your business? Why are they important?

At some point you need to focus and make key decisions that will make a difference in your business. Building your strategic agenda is a different type of challenge and may require another approach. This may take ‘why’ questions, questions that focus on benefits and value. Before adding anything to your strategic agenda you must first clearly establish the benefits and values of those items.

Being honest about your business, the organization and its people is a challenge. When strategic planning it’s important to remove yourself from the natural tendency of coming up with solutions. Establishing solutions is the action part of planning. Consider engaging an expert strategic facilitator to help. Remember that you don’t plan to fail, you fail to plan and planning requires asking the right questions.

Don’t forget to leave your commments below.

Specifying Requirements for Outsourced Projects

Written by Karl Wiegers on September 8, 2014. Posted in Articles. 1 Comment on Specifying Requirements for Outsourced Projects

Rather than building systems in house, many organizations outsource development to contract development companies. They might outsource the work to take advantage of skills they do not have available in-house, to augment their internal staff, or in an attempt to save money or time. The outsourced development supplier could be located physically nearby, on the other side of the world, or anywhere in between.

The role of a business analyst is even more important on these projects than on a co-located project. If the team members are all in one location, developers can walk down the hall to ask the BA a question or to demonstrate newly developed functionality. This close collaboration can’t happen in the same way with outsourced development. Compared to in-house development, outsourced—and particularly offshore—projects face requirements-related challenges such as the following:

It’s harder to get developer input on requirements and to pass along user feedback to developers.
A formal contractual definition of requirements is necessary, which can lead to contention if differences of interpretation are discovered late in the project
There might be a bigger gap between what the customers ultimately need and the product they get based on the initial requirements, because there are fewer opportunities to adjust the project’s direction along the way.
It can take longer to resolve requirements issues because of large time zone differences.
Communicating the requirements is more difficult because of language and cultural barriers.
Limited written requirements that might be adequate for in-house projects are insufficient for outsourced projects, because users and BAs are not readily available to answer developer questions, clarify ambiguities, and close gaps.

This article suggests some techniques for successful requirements development and management on outsourced projects.

Appropriate Requirements Precision

Outsourcing product development demands high-quality written requirements, because your direct interactions with the development team are likely to be minimal. As shown in Figure 1, you’ll be sending the supplier a request for proposal (RFP), a set of requirements, and product acceptance criteria. Both parties will engage in a review and will reach agreement, perhaps with negotiation and adjustments, before the supplier initiates development. The supplier will deliver the finished software product and supporting documentation.

Figure 1. Requirements are the cornerstone of an outsourced project.

With outsourcing, you won’t have the same opportunities for day-to-day clarifications, decision making, and changes that you enjoy when developers and customers work in close proximity. Particularly with offshore development, you should anticipate that the supplier will build exactly what you ask them to build. You will get no more and (hopefully!) no less, sometimes with no questions asked. The supplier likely won’t implement the implicit and assumed requirements you thought were too obvious to write down. Poorly defined and managed requirements are a common cause of outsourced project failure.

As with in-house development, visual requirements models augment functional and nonfunctional requirements for outsourced teams. Using visual models to supplement written specifications is even more valuable if you are working across cultures and native languages, because it gives developers something to check their interpretations against. However, be sure the developers can understand the models you send them and interpret them accurately.

Prototypes can also help clarify expectations for the supplier team. Similarly, the supplier can create prototypes to demonstrate to the acquirer their interpretation of the requirements and how they plan to respond to them. This is a way to create more customer-development interaction points to make course adjustments early in the project rather than late.

Watch out for the ambiguous terms found in Chapter 11 of Software Requirements, 3rd Edition that cause so much confusion. I once read a requirements specification intended for outsourcing that contained the word “support” in many places. The BA who wrote the requirements acknowledged that the contractor who was going to implement the software wouldn’t know just what “support” meant in each case. A glossary is valuable when dealing with people who don’t share the tacit knowledge held by those who are familiar with the acquiring company’s environment.

Acquirer-Supplier Interactions

Without real-time, face-to-face communication you need other mechanisms to stay on top of what the supplier is doing, so arrange formal touch points between the acquirer and the supplier. Plan time for multiple review cycles of the requirements. Use collaboration tools to facilitate peer reviews with participants in multiple locations. Incremental development permits early course corrections when a misunderstanding sends the supplier’s developers in the wrong direction. If the supplier raises questions, document them and integrate the answers into the requirements. Use an issue-tracking tool to which both supplier and acquirer teams have access.

Outsourced projects often involve teams with disparate company cultures and attitudes. Some suppliers are so eager to please that they agree to outcomes they cannot deliver. When an error is brought to their attention, they might strive to save face by not fully accepting responsibility for the problems. Some developers might hesitate to ask for help or clarification, or to say “I don’t understand.” Employ elicitation and facilitation techniques such as reading between the lines for what isn’t said and asking open-ended questions. Establish ground rules with all team members regarding how they should interact when they work together.

Developers whose first language is different than the language in which the requirements are written might not pick up nuances or fully appreciate the implications of certain statements. They might make user interface design choices that you wouldn’t expect. Things as diverse as date formats, systems of measurement, the symbolism of colors, and the order of people’s given and family names vary between countries. The requirements should avoid the use of colloquialisms, jargon, idioms, and references to pop culture that could be misconstrued.

Change Management

At the beginning of the project, establish a change control process that all participants can use. Using a common set of web-based tools for handling change requests and tracking open issues is essential. Identify the decision makers for proposed changes and the communication mechanisms you’ll use to keep the right people informed. The outsourced development contract should specify who will pay for various kinds of changes, such as newly requested functionality or corrections made in the original requirements, and the process for incorporating the changes into the product.

Acceptance Criteria

Define in advance how you’ll assess whether the contracted product is acceptable to you and your customers. How will you judge whether to make the final payment to the supplier? If the acceptance criteria are not fully satisfied, who’s responsible for making corrections, and who pays for those? Include acceptance criteria in the RFP so the supplier knows your expectations up front. Validate the requirements before you give them to the outsourced team, to help ensure that the delivered product will be on target.

Properly handled, outsourcing the development work can be an effective strategy to build your software system. An essential starting point for a successful outsourcing experience is a set of high-quality, complete, and explicitly clear requirements. If the requirements you provide to the supplier are incomplete or misunderstood, failure is probably at least as much your fault as theirs.

Don’t forget to leave your comments below.

About the Writers:

Karl Wiegers is Principal Consultant at Process Impact, www.processimpact.com. Joy Beatty is a Vice President at Seilevel, www.seilevel.com. Karl and Joy are co-authors of the recent award-winning book Software Requirements, 3rd Edition (Microsoft Press, 2013), from which this article is adapted.

Seven Candid Strategic Questions that Every Business Leader Should Ask

Written by Richard Lannon on June 2, 2014. Posted in Articles. 1 Comment on Seven Candid Strategic Questions that Every Business Leader Should Ask

Here are seven candid “what” questions that every business leader should ask:

What are the overall strengths and weaknesses of your business?

What are the overall opportunities and threats to your business?

What political, economic, social and technological conditions impact your business?

Are you developing leaders for tomorrow? Every answer should lead to another question. Dig deep, exhaust yourself and find people to help you through the process.

What do you want to achieve, protect, avoid and eliminate?

Examples vary but could include increased sales, keeping an established portfolio, avoiding trouble or accidents, establishing an employee health program or helping people drop a few pounds. The point here is that whatever is identified must be relevant to your business and its challenges.

What are the key challenges you face today, tomorrow and in the distant future?

We’re in an era where we must be predictive and adaptive business leaders and professionals. Strategic planning is about time frames with past, present and future considerations. Establish what your work world should look like with time frames. Planning used to focus on 3 to 5 year cycles. That has changed. Now we must keep our eye on short-term road trips with long term implications.

Where are we and how did we get here?

This question is a pure honesty question. It is used to establish your present situation and to help you accept complete responsibility and accountability for it. No blame-storming allowed. Outside forces might have contributed, but at some point decisions were made to set your direction. As a business leader, you were either active or reactive and there were consequences. Capture it, leverage it and be prepared to let it go.

What key initiatives are going to be placed on the strategic agenda of your business? Why?

Don’t forget to leave your comments below.

It’s Time to Put Value in the Driver’s Seat

Written by Ellen Gottesdiener on May 12, 2014. Posted in Articles.

Deliver value. It is the mantra of every agile or lean team and a big part of the conversation among traditional or waterfall teams as well. You would expect, then, for all teams to define a product’s value explicitly and transparently—to make it the basis for every decision, the determining factor behind every potential product feature. Yet, too often this is not the case.

Let’s explore how successful teams define value, use it to drive decisions, and consider and reconsider value throughout a product’s lifecycle.

Let Value Be Your Guide

According the Value Standard and Body of Knowledge value is “a fair return or equivalent in goods, services, or money for something exchanged.” In other words, value is what you get for what you give up.

What one company considers valuable, at a certain time, might be completely different than what matters to another company, or to the same organization at another point in time. For example, one team we recently worked with selected a minimum set of product features, or slice of functionality, that could be delivered to their primary end users within two months, so as to stay within the bounds of a highly profitable purchase agreement. Another organization identified the set of features that simultaneously reduced operating costs and flagged conditions in the field that could risk life and limb.

So how did these teams decide on what to deliver? What enabled them to quickly, transparently, and collaboratively select the highest value features? They relied on value to steer their product in the right direction.

Choose Your Destination

Defining a product’s desired result, before building it, is fundamental to that product’s success. As the old saying goes, if you don’t know where you’re going, any road will take you there. Successful agile teams start by determining where they want to finish.

In our first article in this series, we described how product stakeholders from the customer, business, and technology realms become collaborating partners. These product partners envision the product, define goals, and specify measurable objectives, creating a high-level view of the desired product outcomes. These key markers describe and quantify the product’s anticipated value, ensuring that the team is always moving in the correct direction.

One aspect to consider is the tangible, financial qualities, including measures such as IRR (internal rate of return), ROI (return on investment), TCO (total cost of ownership), and EVA (economic value added). Value, though, is about more than money; it is also about intangible aspects, such as user experience, joy, belonging, convenience, sense of well being, trust, alignment to strategy, upsell potential, or brand projection. These intangibles can often be as or more important than tangible value qualities, such as cost or profit margins. Though these intangible considerations are more elusive to measure, they can be quantified by accounting for uncertainty and risk. (For more on this, we recommend Hubbard’s How to Measure Anything).

One of the ways to uncover both tangible and intangible value is to have the product partners explore and share their own value considerations. A value consideration is some variable that is used when assessing the value of your product options. For example, the customer partners might include safety or a convenient-to-use product among their value considerations. Business partners (the people sponsoring the product’s development) might be most concerned about market positioning or protecting the company’s reputation. The technology partners (those who build the product) might be more interested in feasibility and compatibility with existing and future architecture. Making all of these varied (and often competing) value considerations transparent is crucial for making good decisions.

Identify Potential Hazards

Another aspect to consider when making value decisions is risk. Like value, risks change with time and can impede, mitigate, or even obviate delivered value. These risks include rework (if the wrong thing is delivered or technical debt is incurred), noncompliance, opportunity cost, and more. We recommend you consider risks along the same categories as we consider product partners: customer, business and technology.

Dependencies—product and project, internal and external—also constrain product decisions. For example, the partners need to understand the consequences of deviating from an optimal sequence, in both time and cost.

Plot the Preliminary Route

With the guideposts of vision, goals, and objectives in sight, and a clear view of all the tangible and intangible value considerations, the product partners can select the best set of high-value product features (options) for the next planning horizon. (In our second article in this series we define options and describe how teams discover them for all 7 Product Dimensions.) To do this, they consider the costs, benefits, risks, dependencies, and value considerations of each option. They then adjust each option’s value up or down accordingly, always ensuring the option is aligned with the product’s vision, goals and objectives.

Together, the desired outcomes, value considerations, benefits, and risks make up the business value model for a product. The product partners use the value model during discovery and delivery to guide their decisions. In the next article in this series we’ll describe how the partners plan collaboratively, choosing decision-making rules and the timing of the decisions, favoring the last responsible moment.

Adjust Course As Needed

Discovering value isn’t a one-and-done activity. The product partners repeat the process at every planning horizon: the long-term (Big-View), the interim-term (Pre-View), and the short-term (Now-View). Throughout the product’s lifecycle, the partners stay alert to changes in market conditions, availability of resources, costs of delay, etc., and their potential impact on the product, modifying the business value model as needed.

After each delivery cycle, the partners determine if what was delivered actually realizes the anticipated value. This comparison may uncover gaps to be addressed in future releases. Though the Lean Startup movement has made this seem like a new concept, we’ve long had a name for it in requirements engineering: validation. In Discover to Deliver, we call it “confirm to learn.”

Ensure Optimal Visibility

Before value can drive decisions, it must be defined, visible, and well understood by all concerned. Teams need to understand what value means through the eyes of the stakeholders—the product partners from business, customer, and technology. They can then view potential product options (requirements) in the context of these values to choose the most valuable set of features for each release.

When was the last time you collaboratively discussed and purposefully validated your value assumptions? Take some time in your next planning session to honestly and transparently define your product’s value, so that value truly becomes the driving force behind your product decisions.

Don’t forget to leave your comments below.

References:
Gottesdiener, Ellen and Mary Gorman. Discover to Deliver: Agile Product Planning and Analysis. EBG Consulting, 2012.
Hubbard, Douglas. How to Measure Anything: Finding the Value of Intangibles in Business. 3rd edition, Wiley, 2014.
SAVE International. Value Standard and Body of Knowledge. June 2007. Available online here.

Pareto and You – Separating the Wheat from the Chaff

Written by Robert Galen on January 14, 2014. Posted in Articles.

I can’t recall when I first came upon the Pareto Principle. I think it might have been when I was studying for my Six Sigma Green Belt. But I’m unsure. I know I was operating as a QA Director at the time, because most of my example uses for it surrounded testing and defects. Nonetheless, it’s probably been over 15 years.

That being said, I don’t think I hear people “considering” Pareto enough in their day-to-day activity, so I thought I’d bring it up and remind everyone of the Pareto Principle or 80:20 Rule and it’s implications for software engineering in general and agile teams in particular.

Basics

In 1906, Italian economist Vilfredo Pareto created a mathematical formula to describe the unequal distribution of wealth in his country, observing that twenty percent of the people owned eighty percent of the wealth. In the late 1940s, Dr. Joseph M. Juran inaccurately attributed the 80/20 Rule to Pareto, calling it Pareto’s Principle. While it may be misnamed, Pareto’s Principle or Pareto’s Law as it is sometimes called, can be a very effective tool to help you manage effectively.

Where It Came From

After Pareto made his observation and created his formula, many others observed similar phenomena in their own areas of expertise. Quality Management pioneer, Dr. Joseph Juran, working in the US in the 1930s and 40s recognized a universal principle he called the “vital few and trivial many” and reduced it to writing. In an early work, a lack of precision on Juran’s part made it appear that he was applying Pareto’s observations about economics to a broader body of work. The name Pareto’s Principle stuck, probably because it sounded better than Juran’s Principle.

As a result, Dr. Juran’s observation of the “vital few and trivial many”, the principle that 20 percent of something always are responsible for 80 percent of the results, became known as Pareto’s Principle or the 80/20 Rule.

–Quoted from About.com

Implications

Let me give you a couple of scenarios that illustrate “80/20 in action”:

If you’re testing a software application, then 80% of the bugs will reside/surface from 20% of the applications components.
If you’re counting costs, then 80% of the cost of a Toyota Prius, will be contained in 20% of the component parts.
Continuing the Prius example, 80% of the weight, will be contained in 20% of the component parts as well. And if we’re putting them in storage, there will be a warehouse space equivalent.
Back to software, 80% of the technical complexity (perhaps call it risk as well) resides in 20% of an applications components.
And so on…

I really like Juran’s wording around “the vital few”. The 20% turns out to be the interesting case and, once we find it, we can adjust our views to handle it much differently than the 80%.

Disclaimer

Now of course the numbers aren’t quite that precise and I don’t want you to build your every action around or upon Pareto. But making it a part of your analysis and thinking has served me well for years in focusing towards what truly matters.

Agile Implications

Now let’s get around to some of the implications or examples within agile teams:

Backlogs & Product Ownership

20% of the User Stories probably need some sort of “research spike” in order to sort through the technical implications and ambiguity.
20% of the User Stories (functional work) probably contain 80% of the customer value. So find them and do those first.
20% of the User Stories (non-functional work) probably need expanded Acceptance Criteria to better guide the confirmation of completeness.
20% of the User Stories need to be groomed multiple times (discussed, broken down, estimated, explored) before they become “ready” for sprint-execution.
20% of the Features drive probably 80% of the customer usage.
20% of the Features will contain 80% of the stakeholder & customer driven change.

Technical Risk

80% of the technical complexity is in 20% of the component work a team is taking on. Find it and handle it differently: designs and design reviews for example, teamwork and pairing.
The estimates for 20% of the more complex User Stories will be inaccurate or contain more variance. Consider this when estimating.
20% of the backlog will have strong architectural implications.
20% of the backlog will have cross-team technical dependencies.
20% of the application will contain 80% of the technical debt. Or will be attractive targets for refactoring.
20% of the application will require 80% of the maintenance activity.

Planning

20% of the Release Plan will contain 80% of the risk.
20% of a Sprint Plan (backlog) will contain 80% of the value, 80% of the risk, 80% of the swarming opportunity.
20% of the Sprint Plan (backlog) will contain 80% of the testing activity, testing work, testing risk, bugs/rework.
20% of the overall work will take up 80% of the time; I wonder if that has anything to do with “90% Done Syndrome”?
20% of the teams work will result in 80% of the “blocking issues”.

Quality & Testing

20% of the User Stories will contain 80% of the bugs.
20% of the User Stories will contain 80% of the testing complexity and/or repeated testing risk.
80% of the User Stories or Features need less testing than you might originally think—think risk-based testing here.
You’re test strategies and plans ought to include the 80/20 Rule.
20% of the defect repairs will contain 80% of the defect rework.
20% of your tests will take 80% of the time to run; find these and automate them…then go to the beach.

These were not intended as “exhaustive” lists. More so, they are intended to get you thinking of the implications of the Pareto Principle in your daily agile journey.

Wrapping Up

Now all of that being said, there IS a challenge in using the 80/20 Rule.

It’s finding the 20%! It’s not always evident where it is.

Let’s take the bug example. It clearly aligns with my experience that 80% of the bugs “cluster” around a small percentage of the code in every application I’ve ever tested. Let’s call that 20%. So from a testing strategy and planning perspective, 80% of my effort (testing hours) should be focused there. However, finding or predicting those defect clusters isn’t that easy. If I’m presumptuous and think that I can predict them all, then I will most likely have wasted some time and missed some critical areas. So blind use of Pareto isn’t in your best interest nor is it prudent.

However, you should constantly be thinking of Pareto sweet spots in your daily work. It aligns nicely with the Agile Manifesto principles, Lean thinking, and common sense.

One final request: please add comments to this post with other “Pareto scenarios” that you can think of within agile contexts. I’d love to build on the examples I provided.

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

Quick references:
1. The photo is from Wikipedia article on Vilfredo Pareto.
2. http://management.about.com/cs/generalmanagement/a/Pareto081202.htm
3. http://betterexplained.com/articles/understanding-the-pareto-principle-the-8020-rule/