"The Wall of Knowledge"

"The Wall of Knowledge"

There's a good story behind this e-newsletter's title.

A few years ago, we had just begun working on a project the client and we both believed would require a custom-developed application. This presumption stemmed from a large number of client requirements unique to the way they did business in a very specific industry. As it turned out, solving the client's issue did require a custom-developed mobile quoting system, which turned out very well and exactly met the client's requirements (see: They Wanted BlackBerrys...And Then What?).

Even if we start a project where the presumed outcome is custom software, we still need to gather system requirements to definitively conclude whether custom development is required. Assuming so, these requirements guide the application development work to meet the goals needed for success.

We gathered requirements for this other client using a process we've honed over the years — leading a highly-structured meeting evaluating and ranking ideas of key stakeholders. Such a meeting is led by one of our consultants who has already done the necessary pre-work to make good use of the limited time of busy executives and managers. This intense and fast-paced session involves wall charts, sticky notes being placed and then moved (possibly many times), and extensive doodling as consensus forms in the group. At the end of this session for another client, one of the client's staff — looking at the many charts, notes, and colors decorating the conference room wall — termed it "The Wall of Knowledge."

"The Wall of Knowledge" perfectly summarized the content surfaced and captured during that meeting. It was accurate and pithy — thus, it stuck. When we speak internally of a client needing such a session, we just say they need "The Wall of Knowledge" and everyone understands what to do.

This month's case study describes how "The Wall of Knowledge" was conducted as part of a system selection project. There was an especially strong need for this with this client, because they were considering replacing several fragmented systems with a highly-integrated Enterprise Resource Planning (ERP) system — yet, no one at this client had ever been exposed to what such a system could or could not do. Thus, there was an education component to this working session, in addition to the main focus — to gather and distill the key requirements candidate systems needed to possess.

"The Wall of Knowledge" refers to the deliverable from the structured idea-generation meeting, and finds use in many different contexts, including:

• Surfacing and making explicit requirements for selecting a new business, finance, or ERP system.
• Defining specific requirements for a custom-developed application.
• Pinpointing bottlenecks in a critical business area, and agreeing upon steps to reduce or eliminate these.
• Identifying process improvements or technology solutions — both "quick fix" and longer term — by functional areas, and ranking them based on potential improvement in business results.
• Helping a group which is "stuck" look at the situation from different vantage points, including a third-party objective viewpoint.

In the end, the intense session yielding "The Wall of Knowledge" brings agreement on the major "pain points" of the business or organization, builds consensus within the group on business priorities, and clarifies expectations for any solution.

Might a "Wall of Knowledge" project help you and your business? Contact me, and I'll be happy to discuss this with you.

Sincerely,

Todd L. Herman

A Case Study:

Clarifying Business Needs and Issues to Specify Systems Requirements

Situation...

This manufacturing client makes large products on an engineered-to-order (ETO) basis. These products require large quantities of items from many different vendors. Furthermore, many of the larger items need to be serialized and tracked to a specific end product. Our client has an excellent reputation in its industry, and its business is increasing.

Problem...

Several different systems were in use and were not integrated, creating duplicate work and rendering some activities and analyses impossible. The main system was a custom-developed shop floor application, written in a DOS-based database no longer supported, with some additional features from the Windows-based version of the database. Furthermore, the accounting system was old and not particularly strong, and the purchasing and payroll systems were separate from each other and not integrated with anything else.

Solution...

To address the variety of issues caused by disparate systems, we recommended — and the client agreed to — the selection and implementation of an Enterprise Resource Planning (ERP) system. Our first step in any such project is to uncover business needs and issues, and build consensus and a business case for essential systems requirements. We do this by:

• Identifying an internal team of stakeholders for each functional area.
• Discussing and understanding the needs of each individual functional area.
• Distilling information from these discussions into a framework for the next phase, a group meeting of the functional areas.

Once this essential pre-work is done, we are ready to lead a meeting of key stakeholders, typically one from each functional area to systematically:

• Validate goals for each area.
• Identify opportunities for cross-functional process improvements.
• Uncover existing issues with data and current system weaknesses.
• Build consensus around all these items.

A flurry of activity occurs in this meeting, as items are quickly surfaced, charted, and discussed. After this meeting — which typically lasts about two hours — the needs and notes on the flipchart sheets are cross-referenced, grouped, analyzed, and summarized.

Below, this is one flipchart sheet from the needs and issues specification meeting. Our clients have dubbed these sheets — typically covering a conference room wall — the "Wall of Knowledge."

Below, needs and issues from the meeting are analyzed and translated into client-specific system requirements, organized by module or functional area.

Below, pre-work for the meeting yields a good understanding of the "current state" and desired "future state" of the systems, which we translate into diagrams to discuss at the meeting. These diagrams vividly illustrated for our client the changes they could expect — moving from 16 functions spread among 4 non-integrated systems, to a single ERP system integrating all 16 functions.

Results & Benefits...

The final output of this meeting becomes the basis against which candidate systems are screened, the final system is selected, and implementation decisions are managed. In short, the meeting has provided the benchmark and criteria to use in all future phases of the overall ERP project.

Without this clear definition of needs and opportunities, systems cannot be assessed for goodness of fit. With this clear definition, system vendors know exactly what is expected of them and their systems, and how the implementation will be judged as successful — that is, how well it met all of the consensus goals specified in this meeting.

Conclusion...

The agreed-upon needs, issues, and goals force everyone involved in later meetings, demonstrations, and decisions to evaluate systems not on their features, but on their benefits to the business. We then ensure this laser-sharp focus is sustained by client and vendor personnel during the later ERP phases — implementation, rollout, and transition to maintenance.

For More Information...

To discuss how this type of project, or technology usage and business process improvements in general, could be applied to the issues facing your business, call us at 336.297.4200 to schedule a no-obligation consultation, or visit our web site: www.toddherman.com