Skip to main content

Tag: Best Practices

Requirements In Context Part 4: Keeping High-Level Requirements High-Level

This article discusses the importance of keeping high-level requirements (HLRs) at a high-level. It presents examples of functional, data, report, interface and non-functional requirements. Guidelines are offered for each example about things best left to detail requirements. Lastly, it offers suggestions for managing business user expectations during HLR sessions.

What, Not How

Most often the principle “What, not how” is quoted to remind business analysts to keep requirements at the business level, to not jump ahead to design or solutions. But it’s also useful to keep this in mind when gathering high-level requirements, to avoid getting into detail that is best left for detail requirements.

Related Article: Requirements in Context Part 3: Scope=High-Level Requirements

This series of articles is about contexts for requirements. Every high-level requirement should be thought of as a context for the detail requirements that are to follow. Thus, HLRs should not themselves be too detailed (nor take too long to document). One of the most frustrating things a BA can experience is inviting a business user to a detail requirements session and getting the response, “But I already gave my requirements.” Doing a proper job of starting with ‘what’ should make it clear to all involved that there must be a ‘how’ to follow.

High-level Functional Requirements

The “What, Not How” principle should be applied to HLRs about processes. Consider the following requirement about an on-line purchase process:

The system shall not allow a customer order to proceed to the payment step without shipping details having been identified.

On the assumption that the project scope includes delivering an on-line purchase process, the above requirement is very how-ish. If you visualise a workflow diagram of an on-line purchase process, according to this requirement there should be no path leading to the Provide Payment Details activity that has not gone through a Provide Delivery Details activity.

Workflow diagrams that include decision points, loops and such represent the detail of a given process. The only process diagram appropriate when discussing HLRs should be a quick sketch that represented the ‘sunny day’ scenario through that process. Something like the following:

tasker june19

What a sketch such as this looks like as a high-level functional requirement would be this:

The system shall support customers making on-line purchases including selecting products, specifying shipping details, providing payment details and confirming the order.

A truly high-level functional requirement for a business process should be a simple list of its primary activities. If it’s a complex process with many activities, only a ‘suggestive’ list should be included – just enough so that the reader ‘recognises’ what the process is. This leaves the complete set of activities and flow details for detail requirements definition.

NOTE: If an organisation is interested in exploring business process reengineering (BPR) or business process improvement (BPI), this should be a separate exercise from requirements gathering. While it’s true that simply implementing some automation support to an existing business process should have a beneficial effect, those are small-i improvements. The objective of BPR and BPI is to deliver big-I improvements.

High-Level Data Requirements

The following requirement is one I actually saw in a signed-off HLR document:

Each Customer record must be assigned a unique identifier.

This requirement is about one specific attribute of the business entity Customer. Attribute-specific requirements are detail-level. Consider this alternative:

The system shall support establishing new customers, including capturing details such as name, address, and contact information, ensuring that every customer is uniquely identifiable. E.g. Fred Smith assigned customer number 555123, The Carter Foundation assigned customer number 654287.

This version still mentions attributes, but only as an indication of the detail to follow. The phrase ‘such as’ implies this is not an exhaustive list. The idea is to describe a given entity such as Customer by naming just enough attributes and/or relationships so that the reader recognises the concept. It’s the difference between asking someone to name two of the seven dwarves from Snow White and asking them to name all of them. Your subject matter expert (SME) should be able to come up with indicative attributes in seconds. An example or two is another way to ensure that the concept is clear.

From the simple examples included in the HLR above we understand that customers can either be individuals or organisations.

High-Level Report Requirements

Up until now we have distinguished high level from detail level keeping in mind the “What, not how” principle. For reports, we still want to avoid the ‘how’, but the ‘what’ should be augmented by adding four additional Ws – Who, When, Where and Why. Journalism students used to be taught that the first paragraph of a news story should always include information about each of the five Ws.

An example of a high-level report requirement in user story format that includes all five of the Ws is:

As a Customer [who] I want to receive an Order Confirmation that includes details such as the items purchased, amount charged and expected delivery date [what] sent to my email address [where] following the completion of each order [when] so that I have an off-line record of my purchase [why].

The ‘Shall’ version need not be very different – beginning with “The system shall provide a Customer with …”

Some memory joggers as to what reports may be needed are:

  • Event Based – milestones within a process or at its end, or alerts triggered by thresholds being reached
  • Periodic – daily, weekly, monthly or annual reports
  • Statutory – required by government or other regulatory bodies
  • Management – used to monitor progress against plans or budgets

As with the functional and data HLRs, the objective is to set the context for detail to follow. There is really no difference between the need to deliver a function and the need to deliver a report (that is truly needed). There should be one HLR for each, kept to a high-level description that establishes an understanding of what it is.

High-Level Interface Requirements

The previous article talked about context diagrams that represented a project’s scope. The things outside the system boundary in such diagrams represented either types of business users or else other systems. Each system represented at the context diagram level will need at least one interface HLR. These should cover the same five Ws described above for reports. An example of this in ‘shall’ style is:

The system shall support sourcing of foreign exchange rates [what] from the European Central Bank [where] on a daily basis [when] to support currency conversion when the on-line customer [who] deals in a different currency than the supplier of a product [why].

High-level Non-Functional Requirements

There is no question that business information systems must be secure, that they should be usable, and they should perform well. Continuing with the ‘what, not how’ principle, I believe it appropriate to include just a single HLR that lists exactly which NFR types will need to be detailed at some point in the project. This single requirement might be worded something like:

The system shall satisfy details of the following types of non-functional requirements:

  • Security
  • Usability
  • Performance
  • Availability

Exactly when the details of NFRs should be addressed will depend on what the next step of the project is. In the meantime, there is at least one HLR included acting as a context for details to follow.

Gathering ONLY High-level Requirements

The problem with inviting business users to a high-level requirements session is that many believe that this is where they are expected to discuss their requirements. In addition, some bring with them their pain points from the business information system. The ‘unique identifier’ requirement mentioned above was most likely contributed by a user that was having trouble identifying customers.

I would suggest that a better name for an HLR gathering session would be “Requirements Planning.” The invitation should include the agreed project scope items. These set the context for identifying HLRs. The objectives of the session should be stated to be something like:

• To list specific business processes or activities, types of data, reports, and interfaces that are expected to be delivered by the project.

• To identify SMEs for each of these items to participate in subsequent detail requirements sessions.

The previous article in this series demonstrated how ‘starter’ HLRs can be derived from function-based scope items. Having these drafted in advance of an HLR session they can be presented as examples for the appropriate level of detail that is being sought.

Next Time – Where To From HLRs – Build or Buy Context

Where this article highlighted the importance of keeping HLRs high-level, the next article focuses on the importance of detail in detail requirements. We also discuss the rationale for this detail for different delivery contexts (i.e. build or buy).

Pablo Picasso and Scope Visualization

Scope – the last frontier. We are on a mission where no business analyst has gone before. To explore strange new diagrams and to have the project scope clearly understood. Extra credit to those who remember which TV show that was from! Scope and context are the number one reasons business expectations about a project are not met and projects fail.

Let’s face the reality. Projects today are more complicated. In this integrated and connected world of systems, long gone are the days of the quick and easy change. Our organization’s architectural diagrams look like the tombs of Egyptian Pharaohs. Symbols and shapes connected by lines that fill the wall of an entire room. Even trying to explain the diagram to someone can take days.

Related Article: Requirements in Context Pt 3: Scope = High-Level Requirements

Projects now require more involvement by more people. Our systems and processes are so complex and integrated it’s too difficult for one individual to understand them all fully. Stakeholders are flung across the globe speaking many different languages. Top it off with organization’s taking on hundreds of projects at the same time. Keeping track of each project’s scope and impacts to the organization are difficult to comprehend. It’s no wonder why understanding the context of a project’s scope is the number one reason why projects fail to deliver value. They simply lose sight of the project’s vision and goals in our complex systems and processes. Everyone is one a different page. We wind up spending a lot of time trying to get stakeholders, sponsors, and team members to have a clear understanding of scope.

So it’s no wonder that scope and context are the number one reasons projects fail. How can you get an entire project team moving in the right direction? Not understanding the scope and context of a project leads to all sorts of time being spent on just figuring out what we are trying to accomplish with a project.

So how do we get everyone on the same page? By that, I mean the same page in the same book!

It’s time to visualize scope. Scope places the boundaries around where the entire project team will work. Bust out that context diagram. Getting a common, clear understanding of scope and business expectations leads to better projects that deliver real value.

Is that user story a complete representation of the project boundaries or scope? Maybe not. The EPIC or a bunch of user stories combined together would be closer to the bulls-eye. A picture is worth a thousand words. Visualization of scope is worth its weight in platinum as it creates the vehicle to ensure a common understanding of the project scope.

Scope visualization isn’t just about a context diagram. That’s certainly a great tool and I blogged about it previously. Don’t get me wrong – I love my context diagrams. Pushing the envelope a bit, I have used infographics to display project scope in place of context diagrams. In a recent server upgrade project, I was updating the operating systems and consolidating over 1,300 servers. Sticking 1,300 servers on a diagram was an exercise in futility. There just isn’t a big enough piece of paper to display them all. So I pictured things at a higher level. I displayed each server farm as a farm – yup cows and red barn with farmer Joe. The size of the farm was based on the number of servers on that farm. Server farms were in specific locations, so this gave the project team a visual representation of which sites were going to be impacted more heavily. All of this was based on estimates from doing a high-level scan. Remember context is high level.

In each barn was an icon that represented a group of servers. There were 3 groups: leave it alone, upgrade it and consolidate, then retire it. I didn’t have exact numbers or server names at this point, but I knew the servers would be divided into those groups by talking with stakeholders. Servers were put into groups based on our best guess.

In the kickoff meeting, this was a great tool. Sponsor and stakeholders understood in the scope of the project. Yes, they wanted to know more. Everyone wants to know the details, but we were just starting out. Everyone walked out of the room with a pretty good understanding of the scope and estimated size. Many were surprised at the volume of servers in each farm. Overall the infographic did a good job of setting the stage for the project visually. All on one PowerPoint slide.

The idea of scope visualization is to present a single page to provide a high-level overview of the changes the project will make to systems, processes, and people. That’s no easy task. Taking the complex and making it simple is powerful. It creates a better common understanding of the project.

The business wanted a global CRM solution, but all they got were pigeons and index cards.

Context doesn’t just talk about scope – it also sets business expectations about the outcome of the project. It’s important to keep the communication channels open on what is happening with the scope and how the design is being implemented to meet the scope all throughout the project.

I take the concept of the context diagram a little farther than how most folks typically use a context diagram. You know me always pushing the envelope. Context diagrams usually explain the end state or the final outcome of the project. They show the scope of a project outcome.

Building on a good thing, I like to build a context diagram of the current environment at a high-level. Even at a high-level I’m often surprised at how differently stakeholders, sponsors, and team members view the current state. It’s a great tool to get everyone on the same page for the starting point. Having everyone on a different page for what we currently have will cause a few issues down the road in understanding the final destination. Knowing where you are starting from is a powerful thing when explaining where you want to end up in the future state.

Taking this concept even a bit further (and perhaps more uncomfortably) into the desired state. Not many projects really look at the desire of the stakeholders and sponsors. The desire is basically stated in the project request form or project charter. The sponsor and stakeholders put together a vision of the expected outcomes in these documents. A context diagram of the project charter or request which elaborates the vision is a powerful thing. It ensures what is being asked for is understood.

Don’t re-invent the wheel. Many times I take the current state diagram and just highlight the areas that are changing. Simply use color to highlight the add, modify or removes based on the context diagram for the current state. This visually explains where the changes are visualized to occur.

Now you may think I completely lost my mind at this point. Fear not, I’m taking a step even further. I take the context diagram that shows the desired state (based on the project charter or project request) and determine what is feasible. Everybody wants it all but the teleporter to zap you across the globe for break in Paris hasn’t been built yet. Reality always steps in and dictates what is feasible. Taking the context diagram, I highlight the areas that are NOT feasible. It’s a great way to level set the expectations of the sponsor, stakeholder, and project team members.

So when in the project lifecycle does all this context stuff happen? Ideally, it should happen before the project starts at a very high level. Wouldn’t it be great to start a project where everyone understood and was in complete agreement about the project outcome? You can bet it would save a lot of time running around trying to get everyone on the same page. Typically, the context is set at the start of the project.

As you move through the project, more and more understanding is acquired. Details need hammering out, and there is ALWAYS change to the project. Has anyone ever worked on a project with absolutely zero change? If you have, you are leading a very charmed existence. I’m jealous. Context diagrams can help evaluate how change would impact the project. So forget about laminating them and hanging them on the wall. They are living breathing documents that will change throughout the life cycle of the project.

The pitfall is that architects and others might expect diagrams that show the smallest of components. Don’t fall into that pit. Your job is to communicate the boundaries clearly but not make it so complicated a rock scientist from NASA can’t figure it out. Detail is important for design but scope context requires things to start at a very high level and be decomposed into more details. Context is simple with enough detail to make it clear.

Break out your inner Pablo Picasso and get creative. Find a way to display context or scope in a visually appealing manner. Color can help bring greater clarity. Highlight areas in different colors to bring focus to them. If a system is risky or greatly impacted by the project scope, highlighting is a technique to denote that risk. Black & White isn’t your friend. Studies have shown that color diagrams – even with a small amount of color – are more memorable.

Strategy Spotlight: Benchmarking & Baselining Your Organization in 6 Easy Steps

You cannot conduct strategic business analysis or project management without benchmarking and creating a baseline. That is a fact.

I have seen times where executives and professionals skip this part of the planning process, thinking that they have all the information they need to document the current state. I have seen a lot of incidences where these people have been wrong and engage in a form of blame-storming when something was missed.

Related Article: Strategy Spotlight: 8 Common Strategic Planning Mistakes You’re Making

When working on a project, whether a pre-initiative or post-agreed, you need to focus on your benchmark and create a baseline to ensure you are clear about your present situation. A benchmark is a standard point of reference within your industry against which things may be compared or assessed. A baseline is the starting point used to compare your historical performance. Both are connected in the world of business analysis, sometimes interchangeable. The definition can change based on context.

Benchmarking became an important part of business performance management and a key input into financial analysis and business process improvement. It is also a powerful tool in change and transformation analysis forcing executives to look at the reality of the business through the facts. This is a practice that can become extremely uncomfortable for some people at times.

When I was thinking about this blog, I reviewed some of the steps that I have taken to benchmark a client’s internal and external situations. I realized that for me, benchmarking and baselining followed a standard 6 steps of activities.

1. Preparation

You will often hear me say preparation is the key to the success of any engagement. That is the truth in facilitation and in benchmarking activities. In this case, preparation has to do with your initial interviews and discussions with the leadership team to help you understand where their thoughts are at present, focusing on finding out ‘what, why this and why now.’ As part of this preparation, you need to know to what level the stakeholder is invested in the situation. Is it an emotional connection, being dictated from elsewhere or are they just stepping through the steps? This is all important to know.

2. Research

Getting the information you need is all about data collection. Information can be considered primary or secondary. Primary information is an account of the event from an original source. Secondary information is an interpretation of the account of the event.
There are many means of getting the information you need. I often use a three stage questionnaire process with the primary information holders and pre and post interviews to get a present state understanding for benchmarking. I expand my understanding by adding documentation reviews from inside and outside the organization.

3. Analysis

This is a key part of the pre-planning process often requiring information integration, leveling data and checking the sources and facts. You may need to normalize the data to ensure that a direct comparison is possible for operational subjects and issues. The analysis needs to provide comparisons, look at the gaps, cover all strengths and weaknesses, and be improvement focused. By this point you should have a clear state of the company, the project, the industry or application.

4. Presenting

This could be called reporting. It is just a matter of what the deliverable is. Prior to doing any planning type session (workshop, review, discussion), I do a summary of findings. This summary is laid out in such a way that the high-level stakeholders get a story of their present situation and is used for future planning. It is often delivered as a high-level, point form, executive summary with the supporting summary of findings behind it. It is not an extensive report – only a summary of findings. There is a difference. Accompanying a summary of findings might be a 6-slide deck using images to capture the data components.

5. Lessons

I have always liked the expression “forewarned is forearmed”. I think that is what lessons learned should be about, especially when we are doing benchmarking.

During the process, the business analyst should have gotten a clear picture of what I call the “truth”. The issues at play are known, and you should be able to pre-determine how things are going to play out and therefore plan more effectively. At a higher level, the best performing organizations share information and best practices for the benefit of all. If your baseline and benchmark are clear and honest, then you can start to focus on solutions and actions that need to be taken.

6. Actions

It is great to use the word “actions”, but it should not come before planning. In other words, “plan to act” with a well thought out implementation or action plan. This can only be done after the lessons have been accepted, integrated into the key stakeholders thinking (planning team) and the lessons learned can feed into the planning process.

The focus here is what you need to do to go forward based on your benchmark and baseline for your organization with all the common constraints. Dialogue should be forthcoming.

I can’t even remember the number of times that I have been part of benchmarking an organization or system through a combination of interviews, surveys, documentation, industry reviews, and workshop facilitation. I’ve participated in all of these activities just to get a clear picture of the state of things.

I do believe the process can be standardized and applied to any situation where getting clear on the present state is important and benchmarking to internal or external standards.

Developing good benchmarking and baselining skills is important. Chances are you will find yourself following a very similar process each time. I would encourage you to document your approach and share it. It is the place where good business analysis and planning starts. I hope this helps.

And remember:

Be your best, invest in the success of others, and make your journey count.

Richard

5 Challenges for the Business Analyst on a Hybrid Project

Agile has become a common methodology used in many projects, and it’s being used more often. Experts agree that the future is not agile or another methodology, waterfall, but a hybrid of the two.1

Hybrid projects combine methodologies in an effort to use the strengths of both and minimize each of their shortcomings. Implementing a successful hybrid project means needing to have experience with both.

I will give two examples where a hybrid approach will work.

A large project with both hardware and software components can use a hybrid methodology: waterfall for the hardware component and agile for the software component.

Related Article: 5 Lessons From Working With Agile & Waterfall

A second example is a more challenging one: a complex software project where the GUI is created using agile and waterfall is used for feature development.

Hybrid projects strain most of the team members, but it affects the business analysis team more because they have to keep track of everything being developed.

The hybrid project examples from above may be regarded as the separation of church and state. Using waterfall on a hardware part and agile on software part is not difficult, and most likely the BA teams will be separate anyway. “True” hybrid projects are rare, but they will apparently become a reality. By “true” hybrid project I mean a software project where different features are developed using both methodologies at the same time.

In my opinion, there are 5 main challenges a business analyst faces working on a “true” hybrid project:

1. What goes where

Knowing which part of the project will be done using waterfall and which using agile can be complicated. Waterfall tasks can be hardware implementation, application security features, enterprise business architecture, and critical core features. The agile tasks might be GUI design or business features which can change.

Determining what goes where should be set from the beginning of the project. Problems may arise later on if this isn’t done. When issues appear during the project, they should be discussed with the project manager and any other senior members of the team and an informed decision made about which feature goes where. It shouldn’t only be up to the business analyst to decide.

2.  Requirements prioritization and integration

In a hybrid project, feature prioritization may be extremely difficult. The business analyst has to take into account which features will be developed using waterfall, meaning they will be delivered towards the end of the project.
Some features developed with agile might be dependent on the previous ones, and they should be rescheduled toward the end of the project if the prior deliverable is developed in waterfall.

Requirements integration is also challenging because of the same issue: some features will be delivered at the end, others before.

3. Requirements description and documentation

Requirements description is different in level of detail in both methodologies. On a hybrid project, the business analyst must be prepared to do both: requirements for the waterfall part and requirements for the agile one. The problem that might arise is the gap in documentation. Some features will be more detailed (the waterfall ones) and some more high-level (the agile ones).

I think that the most discrepancy will be in the testing documentation because in waterfall the test cases are developed in the analysis phase for all the features. In agile, the test cases are developed for every use case, in every iteration. This means that the application testing will be very difficult overall.

4. Trace / Identify missing requirements

Tracing requirements and, most importantly, identifying missing ones will be challenging. A common mistake is assuming that a certain feature will be developed in waterfall, meaning later on in the project, and business analysts might move on with other tasks.

Another problem is identifying missing features due to fragmented analysis. Some requirements were taken in the waterfall phase and others during agile sprints. Naturally some requirements might be overlooked and never developed. A common requirements matrix must be maintained regardless of the methodology used to develop the feature and business analysts must be involved in both stages of the project – and not have business analysts for agile and business analysts for waterfall.

5. Communication and collaboration

In any project, communication is very important, but in a hybrid one, it’s the difference between failure or success. The BA’s role must be regarded more as a facilitator for the team. The BAs will have an understanding of all the features being developed project-wide, regardless of the methodology, and they will be in a unique position to mediate misunderstandings, provide clarifications, and even help the team understand why a certain feature should be developed using certain methodology.
Personally, I think that “true” hybrid projects are still a long way to go and that most of the hybrid projects will isolate the agile and waterfall methodologies. I think this situation will last for a few years because there are still companies struggling with agile. Companies implementing agile projects still struggle to understand that a business analyst has an important role to play in an agile project and that this role is not obsolete.

Do you think it is feasible to do software development using both methodologies at the same time?

Do you agree the future will be hybrid? What items would you add or remove from the list?

1 http://www.bridging-the-gap.com/traditional-vs-agile-the-future-is-hybrid/

Failing for Success

Failing never feels good because, well, it feels like failure. Nobody wants to fail. We are driven to be number 1, top dog and the big winner. Nobody has ever said, “Wow! That’s awesome! You failed!” The black and white checkered flag falls, and the winner is ordained. The fear of failure is so strong and painful that it’s amazing how far we will go to avoid it. Fleeing, running, hiding, or avoiding it all together.

We put ourselves into a make-believe world where no mistakes can be made, and we overwork ourselves to the point of exhaustion all in the name of ‘not failing.’ We keep ourselves deluded in the belief that failure isn’t an option, and we are at a loss on how to handle failure.

Being fearful of failure, we create elaborate plans to avoid it but it happens anyway. Systems, processes and people just don’t operate with 100% accuracy. If everything ran perfectly every time, we certainly wouldn’t need a helpdesk or second level support.

But failure isn’t as evil as we make it out to be. How did you learn to walk? You certainly just didn’t jump to your feet and start running a marathon. It took lots of trial and error to learn how to put one foot in front of the other to propel yourself forward. Even crawling took some trial and error! After we get on our feet, we forget that in order to get there, we fell, toppled, and wobbled our way to success. There wasn’t a surefire way to learn to walk. We had to fail in order to learn.

Related Article: Avoid These Phrases – Or Your Project Will Fail

Experimental learning has taught us that failure is the best way to learn. Remember back to the days you first started to learn something new like riding a bike. You didn’t do it perfectly the first time and probably fell a few times. Someone was there to pick you up off the ground and put you back on the bike. You learned by failure – that leaning too far one way or another will cause you to fall off the bike.

The last thing I learned was my home thermostat. It connects to the internet and allows me to control the temperature and fan from anywhere. After successfully setting up the thermostat, I started to play around with it. I failed multiple times trying to figure out some of the features. At one point I simply wiped it clean and started over. In learning how to fix the things, I also figured out some cool new ways I could save energy and use it better. I experimented, failed, and learned.

An interesting experiment was performed by Ryan Babineaux and John Krumboltz a few years ago for the book “Fail Fast, Fail Often”. This experiment was simple. A group of students was divided into 2 groups. The first group was told, “You have 90 days to create was many clay pots as you can.” This first group or “Volume Group” was told to focus on volume and forget about quality. The other group was told, “You need to make one perfect clay pot.” The second group was the “Quality Group” and was focused entirely on quality and avoided any kind of volume. Both teams were told they were in a contest to see who could make the best looking and functional clay pot.

You would expect that the group focused entirely on the quality of clay pot would have the most well-designed pot because they were entirely focused on the design. Since the volume group was focused so heavily on just making pot after pot, odds are none of their pots would be that well designed.

At the end of the 90 days, both teams put all their pots out for judgment by a panel of clay pot artists and experts. I’m don’t know who these people are, but I will say they have one incredible niche job for judging just clay pottery. Can you even make money at that?

The surprising result was that the volume team that just made as many clay pots as they could won the competition. How is that even possible? Why did volume win out over quality?

The quality team has so focused on quality and creating the perfect design that they didn’t take any time to experiment or play with the clay. The volume team, on the other hand, interacted with the clay constantly. The first few clay pots produced by the volume team were damn ugly, but they continued to play and experiment. The volume team while trying to achieve a greater volume of clay pots actually learned more about creating clay pots and were more comfortable with the clay. So even though the volume team had a lot of failures, they succeeded and won.

Failure can make you stronger and more agile if you choose to learn from it. “That didn’t work – let’s try something different” attitude. This is the whole concept around failing fast. The faster you fail, the more you learn from that failure. Don’t fail just once, fail multiple times.

Failing safe is about creating an environment where experimentation and learning do not cause injury to yourself or your organization. Like in the experiment, an environment needs to be created in which experimentation can occur with wild abandon safely. No one was harmed in the making of clay pottery.

In the technology world, we use the term “prototyping”. Many prototyping situations in technology are severely limited. The environment is too confined or restrained for experimentation, and often very few failures occur to learn from. A better safe environment in on that this not restricted and open for experimentation.

Playing and changing everything in a production environment where your customer experiences your experiments has a tendency to make your customers unhappy. Build an environment where you can play without consequence. You may have to start over from scratch and rebuild the environment after a wild night of experimentation. Plan on creating a way to rebuild your safe environment quickly so that experimentation isn’t slowed down.

Create other safe and soft landing environments where you can bounce your ideas of others. Maybe your environment isn’t about a physical space or system but a room filled with flip charts and whiteboards.

Pulling together a group of colleagues to idea share, collaborate and innovate creates a safe environment as long as ground rules and expectations are set ahead of time. Set the expectations that experimenting and innovating is the goal. The more ideas, the better. We are not driving for perfection. It’s like a brainstorming meeting on steroids. Encourage crazy ideas and actually try it out. There are no judgments and the wildest crazy ideas are always welcomed.

Another tactic is to experiment with screen or report design by having multiple variations mocked up. The key is not just to focus on one mockup but to have many mockups. This allows the group to “riff” off each other by taking elements of different mockups and combining them together in new exciting ways.

One of my favorite tactics is user experience development and testing space. User experience folks will tell you it’s a preferred tactic to have users just play with your interface (screen or report) and watch how they use it. Gather a group and invite them to play or experiment with a design. The designers in the room are silently watching actual users interact with their design. The designers learn from watching the group play and experiment with the design. Designers then change the interface based on their observations. Rinse and repeat. One session is usually not enough. They key here is not to tell the user how to use the interface but to let them play and experiment freely in a safe environment.

A badass professional can open themselves up to new experiences so they can learn. They understand that failure can happen and work to create safe environments in which to play and experiment. Our culture needs to change the way we see failure. We must start seeing failure as an opportunity to innovate and not as something bad.

To succeed without learning is a failure. There are many instances in my life where I have executed a task perfectly the first time only to fail the second time miserably. Beginners luck can be a curse because you miss the opportunity to learn from failure. Only through failing do we truly learn.

A badass professional is reflective in their failure but not to the point of obsession. Look back and determine if there was a lesson to be learned. What went well? What didn’t go so well? What still baffles me? What if I did something different instead? Then get up off the warm fuzzy safe pillow in your safe environment and try it again. Remember you didn’t learn to walk without falling first.

Take the example of switching jobs. You prepare that killer resume and get in the door for an interview. You did your homework on the company and prepared yourself for the usual interview questions. It seems like everything went well but you didn’t get the job. Learning from failure requires being reflective or thinking about it. This shouldn’t be an all-day marathon conversation going around in your head. Jot down a few things you thought you could do better. Follow-up and get some feedback from the interviewer if you can or a colleague on interviewing better. You failed to get the job, but you succeeded in learning how to do it better next time.

Let’s build a strategy together on how to help your organization fail in a safely and fail faster so they can learn and drive innovative new solutions and approaches.