Buy-in drives change forward and dictates the success of any approach or change. An organizational change is only effective if it is supported at the highest level of management and filtered down throughout the organization, otherwise the process of change can be difficult.  In almost all cases true change requires buy-in coming from the top down (senior management) as well as from the bottom up (from operational management). While both forms of buy-in are essential to implement change, senior management buy-in can often times be cascaded down to operational staff quite effectively. Conversely, it is harder for buy-in from operational staff to be pushed up to senior management. Regardless of whether buy-in comes from a top down or bottom up direction, if buy-in is not achieved at all levels of the organization any change within an organization is likely to fail.

One of the first things to consider when establishing buy-in is to establish a team of champions at both senior and operational levels to ensure top-down and bottom-up acceptance of the proposed change. This will significantly improve internal communications between the business units involved in the proposed change. It will also enable the development of “trust” between the participating teams, which help support the sharing of information.

If Senior Management does not follow the proposed changes, the lack of buy-in will guarantee its eventual decline and failure. A few initial steps can be undertaken to help ensure both buy-in from Senior Management and the success of the new endeavor.

• Understand the short and long term needs of the business.
• Make sure that your proposed change strategy is aligned with overall business goals.
• Measure the existing level of support for your proposed changes before starting.
• Review and use goal-setting materials. The SMART method of developing goals may help you achieve success in implementing your new change strategy. SMART goals are specific, measurable, attainable, relevant and time-conditioned.
• Deliver on time throughout the change life cycle, building credibility with Senior Management as you achieve each milestone.
• Avoid surprises by discussing issues before they become problems with Senior Management. Doing so will assure Senior Management you are on top of problems associated with your proposed changes before they even occur.
• Throughout the change process always present facts, not opinions.

Even with Senior Management’s buy-in, lack of buy-in from operational management can have such a negative cultural impact on a new endeavor that it is derailed before it even begins. The following steps will help in establishing and maintaining bottom-up buy-in throughout the change process.

• Develop implementation content for the proposed changes that are specific to each operational department.
• Deliver the proposed changes with a Senior Business Leader to show both support and buy-in from the start.
• Follow up with a session to review the proposed changes with each operational department.
• Observe your change strategy in action within departments. All of the affected departments should demonstrate equally high levels of support for the proposed organizational changes.
• Meet with operational managers regularly. Keeping connected with each department during the transition will prevent minor issues from becoming real problems later on.
• If one or more departments do not buy-in to the changes, meet with each department individually and discuss their concerns. Adapting discussion techniques such as a Brainstorming, Round-Robin, Planning Poker, etc. to list and then rate the level of each concern within each department will help you and the department identify the true impediments to change implementation and help direct resources where they are needed most.
• PR what you do and make sure to give credit where credit is due. Recognition for those doing the work in each department will help you maintain momentum throughout the entire change process.

While not an all-inclusive list, the above steps will assist in helping change implementation become successful. Most failed change implementations fail before they even begin, not because the proposed change was not beneficial for the organization, but because the necessary buy-in was never achieved at the outset.

About the Author:
Mark Townsend is a Senior Business Analyst with OneSpring LLC (www.onespring.net) in Atlanta Georgia. Mark has over 15 years of experience in Process Design, Business Analysis, Product Development, and System Implementation.

As an organization grows, and its use of Requirements Design Patterns matures, its quite common to be faced with a large amount of patterns with uncertain contents.  To address this concern, it is recommended to designate a single contact or team of contacts as a Pattern Manager or Pattern Management Team.  The decision to select one or several people should depend on the size of the organization.  Typically, the person or persons fulfilling this role are experienced Business Analysts within the company and are familiar with addressing the challenges of managing requirements across multiple projects.

The Pattern Manager or Pattern Management Team typically manages a Requirements Design Pattern Library, which is a central repository where all Design Patterns are stored.  The team also maintains an index, typically in the form of a spreadsheet or internal Wiki, which contains  the pattern ID, Name, Hyperlink to the Pattern, Version, and Description of the Pattern.  The index is the “go-to reference” for Business Analysts within the Enterprise, and provides a straightforward way to review pattern contributions.  As patterns are identified and created on individual projects, they can be submitted to the Pattern Manager or Pattern Management Team for review, and inclusion in both the Library and Index.

Depending on the size of the Enterprise, a variety of tools may be available for maintaining Requirements Design Patterns.  A solution such as Microsoft SharePoint can version patterns automatically, is offered by a number of storage hosts on the Internet, or can be hosted internally.  Cloud-based solutions such as Google Docs, or Dropbox can also accomplish pattern management.  For organizations that utilize internal wikis, it is fairly simple to build out a series of pages to facilitate pattern management.  Even if these tools are not available, pattern management could be accomplished by way of something as simple as a folder on a shared network drive.

With a total picture of Requirements Design Patterns now in mind, consider it a challenge to explore the benefits of deploying such patterns today in your Enterprise.  We strongly believe that such an approach can save your teams time, and improve overall requirements quality, which should ultimately result in a positive impact on both your project delivery schedules and bottom line.

About the Author

Chris Staufer is a Sr. Visualization Analyst with OneSpring. When he’s not developing innovative ways to document requirements for federal and corporate customers, he enjoys practicing martial arts and spending quality time with his wife. Chris lives in Atlanta.

Here are four such articles that we believe are worth taking a look at, broken out by subject area:

Program Management

Agile Program Management
by ScrumAlliance

Requirements

Agile Analysis, Agile Testing: Synergies for Successful Software Solutions
by ebgConsulting

Requirements for the App – Tips and Tricks for the iPad World
by Remzil Kulkarni for businessanalysttimes

Visualization

A Taxonomy of Visualization Techniques
by Jeffrey Heer, Ben Shneiderman for acmqueue

Enjoy!

About the Author

Chris Staufer is a Sr. Visualization Analyst with OneSpring. When he’s not developing innovative ways to document requirements for federal and corporate customers, he enjoys practicing martial arts and spending quality time with his wife. Chris lives in Atlanta.

A Design Pattern is defined by Wikipedia as: “… a formal way of documenting a solution to a design problem in a particular field of expertise.”  Think of a Requirements Design Pattern as a reusable “Requirements Widget” that has prior approval for use within the company, and that can be quickly applied to new situations.

Requirements Design Patterns typically have the following attributes:

1. ID: a unique identifier used when referencing a pattern
2. Version: for tracking changes and approvals
3. Name: name of the Design Pattern, such as “Login Widget”
4. Input: any inputs required for the pattern to function
5. Output: the expected output or result of applying the pattern
6. Description: a detailed description of the pattern, and any clearly defined inputs or outputs relevant to when the Pattern is applied.
7. Requirements Detail: the detailed requirements associated with the pattern.

Example:

ID: 1
Version: 1.0
Name: Login Widget
Input: Username, Password
Output: The user is logged in and taken to their homepage.
Description: The Login Widget is the form present at the top right corner of our corporate websites that allows a user to login to access their homepage.
Requirements Detail: [Detail for the requirements related to the Login Widget.]

A good practice is to review Requirements Design Patterns like any traditional requirements documentation, and then once approval is obtained, to version and track it in a central repository, where Business Analysts can easily access it across the Enterprise.  If your company leverages Visualization technology, requirements can often be documented in the Visualization itself, so that when the reusable component is applied to a new Model, the requirements are added automatically, resulting in significant time savings.

In the fast moving world of software development, it’s tempting to want to simply focus on only solving the problem at hand, rather than developing a solution that can be applied and leveraged by others to solve problems in the future.  Consider it a challenge on your next project to develop some reusable Requirements Design Patterns of your own, and then share and champion them; you would be amazed at the time and cost savings that can result in the future by developing a single reusable solution today.

About the Author

Chris Staufer is a Sr. Visualization Analyst with OneSpring. When he’s not developing innovative ways to document requirements for federal and corporate customers, he enjoys practicing martial arts and spending quality time with his wife. Chris lives in Atlanta.
 
 

One of the most effective ways of dealing with this is through the setting of goals associated with the new process. Asking the development team to meet certain goals before suggesting and making changes to the newly implemented Agile process helps the team learn the entire process and learn what will and won’t work before changes are made. One example goal is to require that the development velocity increase by 200% before changes are made. Other mangers require X number of development or scrum cycles to be completed before changes are proposed. Most often though asking the team to meet a performance improvement goal works best. Performance goals encourage the team to become completely dedicated to Agile’s success while simultaneously demonstrating Agile’s value to parts of the organization not directly involved with the newly implemented processes.

In following the decision to require certain goals be achieved before making changes to the Agile process, it is equally important capture suggested changes as soon as the team brings them up. At the end of each sprint a Retrospective is usually held. This is the ideal time to discuss process changes, document what the suggested change is, what event generated the suggestion, and how critical the change may be to the success of the Agile process. It is also suggested to update the team during the Retrospective with their progress towards their goal. As the team gets closer to achieving the performance goal necessary for changes to be made review both current and previous improvement suggestions. This initial settling in period before implementing changes will help the team properly identify improvements that will provide the biggest benefit to the team. Issues that occurred once and appeared critical at the time of occurrence may be proven to be either minor or a non-issue once the team has become more comfortable with the new Agile process. This settling in period will allow the team to review all of the suggested changes and chose which improvements are best suited to help the team achieve long term success.

However you chose to implement Agile it is important that you take definite steps to ensure Agile is not derailed before it has a chance to succeed. Delaying process tweaks, unless something is an obvious and undeniable roadblock to success, will help ensure your success and the success of Agile.

About the Author:
Mark Townsend is a Senior Business Analyst with OneSpring LLC (www.onespring.net) in Atlanta Georgia. Mark has over 15 years of experience in Process Design, Business Analysis, Product Development, and System Implementation.

Most organizations begin by using a pilot type approach. A small team is usually used to initiate the pilot before it is rolled out to the entire organization. This type approach usually involves a team of experienced personnel and the thought leaders from the Development Team. It also tends to be less stressful, guarantees early wins for the new process, and allows for refinements to be made before transitioning the organization as a whole. Cultures that accept change but do not handle large tumultuous change without first testing, reviewing, and refining things often times benefit from this approach most.

Going “All In” is, as one might expect, a much more radical approach for any organization. Whether it be Agile, Waterfall, Lean, or any combination of approaches, an All In approach can be very effective. All in approaches are most often used if the organization finds itself on either end of the “Acceptance to Change” spectrum. Organizations with a low resistance to change most often chose to go All In as it proves to be faster, more efficient, has a lower associated cost, and allows the organization to get up to speed faster. The same All In approach can also be used in organizations with an extremely high resistance to change. Just as Cortez burned his ships to demonstrate to his men that there was no turning back, an All in approach may be needed to show overly reluctant and resistant members the necessity for them to buy-in and drive the new development system to success. This approach may cause a high amount of initial turmoil with resistant team members but it helps ensure the initial stress will be over sooner rather than later. An All In approach may also help to prevent less than full effort outside the pilot team from derailing your initiative before it starts.

In moving to Agile there is no right or wrong way to go about executing change, only expectable and/or tolerable ways agreed upon by you and your organization. In most cases successful adoption of Agile starts with management’s buy-in and choosing the correct approach for your organization through unbiased analysis of your organization, its culture, and the true reasoning facilitating the desire to move to Agile.

About the Author:
Mark Townsend is a Senior Business Analyst with OneSpring LLC (www.onespring.net) in Atlanta Georgia. Mark has over 15 years of experience in Process Design, Business Analysis, Product Development, and System Implementation.

The concept of Agile Requirements Definition and Management (RDM) is not a new concept. However, the struggles to figure out how traditional requirements cycles fit within an Agile framework remains convoluted. For a system to work, an organization needs to think about the entire lifecycle and not just the software development portion. If you start at a high-level within your company and analyze what documentation is being produced in order to create finished code, you’ll most likely find that over 50% of the documentation created was not used. Why are we creating waste?

One theory relates to the complexity factor. As a system starts to mature it starts to move toward complexity. It becomes increasingly difficult to understand, organize, manage, and maintain these systems. People have a tendency to add more to the system to help fill gaps and create protocol to maintain and control it. As organizational turnover occurs and the rules, regulations, and business climate change, the system must also adapt. This causes the complexity of the system to grow exponentially until it gets to the point where it is difficult and/or prohibited from functioning properly. This is precisely why the best systems, or for that matter products, are simple and streamlined. This is exactly why Lean Thinking removes waste from the system. Requirements Definition and Management is no different in its vulnerabilities to the complexity factor. This is why companies sometimes end up with requirements specifications that are hundreds of pages long and extremely difficult to follow and manage.

If you’re looking to adopt Agile and want to run a leaner operation, you have to take a holistic view of the organization. Requirements definition in Agile has to be looked at through a separate lens, not strictly in conjunction with the development team. The same principles used in Agile software development can be applied to requirements definition and management as well. Let’s look at a quick example of how this works. There are various Agile frameworks out there, but the most popular is Scrum. Other frameworks include XP, Crystal, and Kanban to name a few, but Scrum is the most commonplace so we will use this for demonstration purposes. It is also important to mention that some of these frameworks can be combined. For example, portions of Kanban can be used within Scrum to control team capacity constraints by limiting work in progress (WIP).

Scrum allows development teams to build software incrementally over 2-4 week events called Sprints [see Figure 1]. Requirements are fed into a Product Backlog prior to Sprint inception, which gets decomposed into Sprint Backlogs Items through Sprint Planning. The development team starts by discussing what needs to be developed in a given Sprint based on the organizational needs and strategy. The work items are pulled from the Product Backlog and directed by a Product Owner, with the process being controlled and managed by a ScrumMaster. The goal for the business is to make sure they feed the Product Backlog and can support and describe what needs to be built by the development team prior to the Sprint starting. The problem is that most organizations struggle with keeping pace and/or don’t have the right level of detail defined in the Product Backlog to properly tie into the development Sprints.

Figure 1: Scrum / Sprint

Agile Requirements Definition and Management was specifically design to solve this problem by outpacing the development team. This is accomplished by feeding the Product Backlog faster than the development team can produce code. The framework can be used for just-in-time requirements definition or to build a repository of requirements for future use. In either case, if a team is using Scrum they are working from the Product Backlog. Since the Product Backlog is a “backlog” of work, the required pace of filling the backlog is driven by the designated Sprint timeframe. The goal is to make sure the business (i.e. Product Owner) can clearly articulate what needs to be built and that what is define is of high quality. To accomplish this the Requirements Cycle follows a Scrum-like process that mirrors the development cycle but stays two to three steps ahead [See Figure 2]. The goal is to create a process by which requirements can be thoroughly vetted, organized and communicated that is iterative, timely, and quality-focused.

Figure 2: Agile Requirements Definition and Management (RDM)

It all starts by identifying and filling a Requirements Backlog. This type of backlog is a list of items that need to be defined in order to fill the Product Backlog. The end goal could be User Stories, Visualizations, Functional Requirements, etc. The requirements team decides based on the business strategy and objectives what needs to be defined and built through requirements planning and prioritization. Like the development team, the requirements team would plan their Sprint, perform the work, and review the outputs. If the outputs meet expectations then they can be moved to the Product Backlog. In many cases, organizations will have documents that need to be created to pass certain tollgates or organizational milestones. These items can also be put in the Requirements Backlog but may not end up in the Product Backlog. Instead, these documents in many cases become reference material for the development team to pull from. This is where traceability from the Product Backlog to any external documents becomes important to establishing project continuity.

Another important portion of RDM is called Decomposition. Decomposition is the process by which the Product Backlog Items are communicated and refined in collaboration with the development team. Decomposition can be used in several ways. One such way is to setup a culture of collaboration where the development teams are brought into the requirements phase to refine the Product Backlog. In Scrum, this is commonly referred to as grooming the backlog. Another way to use Decomposition relates to procurement and/or timing delays. Some projects experience gaps in time between when requirements are defined and when development starts. There are many reasons why this happens but it is important to note that this occurs on a regular basis. The larger the gap in time between definition of requirements and development, the more risk that occurs with developing the right product. Loss of vital team members, knowledge and overall team availability all are at risk the longer the gap. Decomposition in this case is used as a way to pick up where things left off by using the Product Backlog to communicate and share requirements.

Agile is quickly becoming the most popular way of developing software because it fosters continuos improvement, time-boxed development cycles, and delivering value to the end users faster. That value will be driven to a large extent by the quality and clarity of requirements that feed the software development process. An agile, lean, and timely approach to requirements as the starting point will help to ensure that your process is optimized.

There are many flavors of Agile on the market today, I’ve discussed but a few of them in this article. The key is to figure out what works for your organization and to start experimenting. The faster you dive into trying to be more Agile, the faster you will start seeing the benefits it brings.

About the Author:

Jason Moccia has over 14 years of experience in the software development field and is a co-founder and managing 
partner of OneSpring LLC (www.onespring.net), where he oversees the Federal business practice as well as Operations. OneSpring helps companies to work smarter by providing an entirely new approach to software requirement definition.  

In addition to Mr. Moccia’s leadership role within OneSpring, he has also worked as a senior business analyst with numerous Fortune 1000 companies—including, but not limited to, Ernst & Young, General Electric, SAIC, Florida Power & Light, InterContinental Hotels, Deloitte, and SunTrust. Mr. Moccia is a Certified ScrumMaster (CSM) and holds a Bachelor of Science degree in Business Administration from the University of Florida with a focus in Management Information Systems (MIS).

The use of Agile Requirements Definition and Management (RDM) solves this problem by going through several prioritization cycles during each project. RDM follows a lean thinking philosophy of waste reduction and continuous improvement, therefore, each iteration or Sprint allows the team to pause and reflect on whether they’re aligned with the business objectives, or not. It also insures that the requirements defined at the end are properly organized and prioritized for development consumption. This helps reduce cycle times and any project lag that may occur between requirements and development.

About the Author
: Jason Moccia has over 14 years of experience in the software development field and is a co-founder and managing 
partner of OneSpring LLC (www.onespring.net), where he oversees the Federal business practice as well as Operations. OneSpring helps companies to work smarter by providing an entirely new approach to software requirement definition.

Key topic areas include:
-The basics of Agile (terminology, roles, sprints, backlogs and more)
-The variations of Agile (XP and SCRUM)
-The difference between Agile, Waterfall, RUP, and more
-How government agencies are attempting to adopt Agile
-The pros and cons and strengths and weaknesses of Agile
-Approaches to implementation in the Government environment
-How software visualization is becoming an integral part of the Agile process

The goal of the session is to share knowledge and bring individuals together to discuss what they’ve learned around Agile development in the Federal government.

To learn more and/or register, go to PotomacForum.org (http://potomacforum.org/?view=476)