Ok, I will confess that I am a process improvement fanatic. I suppose it has something to do with my experiences early in my career working in a TQM environment at TSYS, and working with a key customer (AT&T Universal Card Services) to win the Malcolm Baldrige Quality Award. In reality, though, it probably has more to do with my desire to create “well-oiled machines” and tinker with numbers.

So what is process improvement anyway? Well, let’s first consider a definition of a “business process”. Tom Davenport lays it out pretty well:

”a structured, measured set of activities designed to produce a specific output for a particular customer or market. It implies a strong emphasis on how work is done within an organization, in contrast to a product focus’s emphasis on what. A process is thus a specific ordering of work activities across time and space, with a beginning and an end, and clearly defined inputs and outputs: a structure for action. … Taking a process approach implies adopting the customer’s point of view. Processes are the structure by which an organization does what is necessary to produce value for its customers.”

Some basic examples of processes – the way that your company:

• drafts and approves proposals and contracts for your customers
• performs implementations/installations for your customers
• performs software quality assurance testing, logs defects, etc.
• submits and approves expenses
• hires new employees

The art of “process improvement” can therefore be generalized as applying some series of additional activities in an effort to improve existing processes. Improving is a relative term, of course, but in general, you are most likely seeking to decrease something (e.g. number of software defects, the time necessary to pay out expenses, etc.) Process improvement can be a huge strategic advantage for a company; however, it can be one of those proverbial roads that lead to nowhere, paved with good intentions and failed initiatives.

Process improvement is generally accompanied by overhead - and overhead is rarely something to get excited about. Conversely, shooting from the hip and hoping that processes get better on their own is not going to be a productive path either. So where does that leave us?

Sometimes it can be hard to do process improvement, when you have no processes at all – or no product. You see this quite often in startups and early-stage companies. Everyone is focused on getting to the next milestone, and improving processes is something you’ll “tackle later.”

But let’s suppose there are some processes in your small company that you want to improve. Trying to implement modern process improvement tools and strategies such as Six Sigma or TQM would equate to overkill in most cases. You’d spend most of your time trying to track and capture data, and not enough time innovating. Creativity is critical to startups – and obviously, you don’t want to introduce anything that is going to stifle creativity. In fact, there was a great article on this in Business Week a few months back – excellent reading. The article is called “3M, A Struggle Between Efficiency and Creativity“, and is a must read if you have an interest in this space. It is a thorough treatment of how Six Sigma was used to make 3M an incredibly efficient company, at the cost of stifling creativity.

So how do you begin to improve your processes, without trying to kill a fly with a sledgehammer? A good alternative for early-stage companies is the concept of the 5-whys, as used by Toyota. Simple, elegant, and completely pragmatic – all of the traits of the modern startup.

Essentially, it is a method of asking questions to arrive at the root cause of a problem. Ultimately, you want to explore the cause/effect relationships that feed into any given process or problem. For example, let’s say that while doing a demo to a key new customer, your software product kept crashing with embarrassing errors, and the customer backed out of the deal. Clearly, this is a problem that needs to be addressed. Instead of breaking out Six Sigma methodologies and trying to improve all of the many things that feed into that software, you simply ask the question “Why?”. it is important to point out that the gut reaction of any salesperson in this scenario would be to blame it on the software (“damn engineers, they keep pushing out buggy code!”). But once you start digging, things can often play out differently.

• Problem: We lost the deal.
• Why? The demo crashed.
• Why? The code is obviously buggy.
• Why? The engineers aren’t paying attention to detail and testing thoroughly.
• Why? The engineers didn’t have enough time to test.
• Why? The customer wanted a last minute feature added in, and there wasn’t enough time available in the project plan to do testing.

Obviously, you don’t have to limit yourself to five questions (whys), but you get the idea. Once you arrive at the root of the problem, you can address it with a laser focus. In this case, there would appear to be a broken process around how change requests from customers are factored into the project plan. So instead of running down the hall and throwing inanimate objects at the nearest software engineer, your energy is probably better expended by working with your project management team to ensure that it doesn’t happen again.

Granted, this is an incredibly basic approach to solving problems, but it works. It is time-efficient, and allows you to implement spot solutions to address deficiencies quickly.
Six Sigma and other types of methodologies are cool – especially if you love to crunch numbers. But again, implementing those in a startup is, in my opinion, overkill.

There can be a case, however, for certain processes within a startup to be measured with something like Six Sigma. Especially if the process is an automated one, and something that is at the core of your business. In such cases, it probably makes sense to do more robust data gathering and analysis (viva DMAIC!).

Cheers.

Abstract: Off-shoring of software development, maintenance and support activities is an established means of driving down costs and improving a company’s competitive position in the market. However, many off-shoring efforts fail to fulfill the promise of low costs and high quality, due to unexpectedly high setup and operational costs, massive rework and low quality.

Off-shoring poses all the familiar challenges of building a new software development organization – challenges which, despite significant research, decades of experience and countless papers, are still causing many companies grave problems. In the case of off-shoring, all these challenges are amplified by geography, cultural differences, infrastructure complications…

As with many other challenges, there could be multiple keys for off-shoring success. This presentation explores a number of them:

• Defining your needs and criteria for success: why do you need off-shoring? Is the major goal cost reduction? Improving time to market? What are the criteria for success?
• Off-shoring model selection: will a group of developers out there be an integral part of your organization or a separate organizational entity? Which one is better for your company? What are the criteria for making the right decision?
• Planning for off-shoring: how to prepare? What do you need to change in your organization to make off-shoring successful? What processes should be changed/ developed to make off-shoring successful?
• Solution Development: how do you translate the plans into action? and specifically:
• Selecting an off-shore entity
• Streamlining your existing software life cycle
• Tracking progress and quality by process and product metrics
• Defining and implementing management controls
• Creating efficient quality assurance mechanisms

Bio: Michael Yudanin’s area of expertise is software processes assurance. Translated into practice, it means creating life cycle models that fit organizations’ needs and constraints, establishing verification and validation activities throughout the software life cycle, off-shoring process and product assurance, logo certification testing, test automation, organizing and managing testing efforts for new development and implementation, designing software processes to fit CMMI® and ISO requirements, as well as other applications of quality in information technology.

Michael is a founder of Conflair – an IT Solutioning Company. IT Solutioning is an operational philosophy that emphasizes development and implementation of custom client-centric solutions rather than provision of a number of well-defined services certain company knows how to do well. Throughout his career Michael worked with a large number of companies, among them: Centers for Disease Control and Prevention, United Parcel Service, Sage Accounting, Ceridian, Comverse, Georgia Department of Transportation, Tennessee Valley Authority. Michael Yudanin is a Certified Software Quality Engineer by the American Society for Quality since 1999.

Check the Atlanta SPIN web site for the latest details and directions. Come out for some great networking with some of Atlanta’s top software development professionals. The free pizza is a bonus!

See you there!

Cheers.

As a quick refresher, in a JAD context, the functionality matrix represents a prioritized collection of the major functional components of a proposed system. These functional areas were, hopefully, agreed to by all relevant stakeholders who attended the JAD session(s) that went into its creation.

Before we go further, it is important to point out something. As much as it pains me to say this, my way is not the only way, nor is it necessarily the best way. It has worked for me consistently in the past, however. Hopefully, at a bare minimum, this article will at least give you a framework on which to build your own method(s), or at least spark your imagination a bit.

Before creating the functionality matrix, I recommend having the scribe, or some other able-bodied person, take the controls of a laptop and fire up Microsoft Excel. Excel represents a fast and easy way to collect and tabulate data. Excel will become even more important later on, when we begin doing some calculations. If at all possible, I would recommend being in a room where the laptop can be projected onto the wall. By doing so, everyone in the room can participate in the creation of the functionality matrix.

At some point during the JAD session, you, as the facilitator, will lead the group through a series of exercises in order to capture the broad requirements of the system. For many new facilitators, this part is the hardest, however, it doesn’t have to be. It really, truly is amazing what happens when you simply ask “ok, what, at a high level, does this system need to do?” The general flow will be as follows:

1. Brainstorm ideas
2. Streamline the ideas by grouping or removing
3. Go to step #1 and repeat as needed
4. Prioritize the final list of requirement categories
5. For each high level requirement area, go to step #1 and repeat as many times as necessary (to capture the detailed requirements).

When brainstorming requirements, it is important to capture each and every idea. Some ideas will be great. Some will be so-so. A few will be completely worthless in the end. But capture them all. By doing so, you are guaranteeing that every voice is behind heard; at least once. Many JAD sessions fail because consensus was not attained, or voices go unheard.

The process of brainstorming is used to quickly and efficiently capture a stream of ideas. It is not a time for discussion, and certainly not the time to argue one’s case. If you catch your participants doing this, it is imperative that you remind them of this! Capture first, discuss later.

It is practically impossible to instruct someone how to conduct a brainstorming session. The easiest way to learn is to participate in one. However, here is a small sample of the general flow of a session:

Facilitator: Ok, we are now ready to capture the high-level requirements of this new system. We are using a brainstorming session, which means no discussions, only ideas! We have 10 minutes for this, so just blurt them out. As you call them out, I will write them up here on the whiteboard. Mike, our scribe, will also capture all of the ideas on his laptop for use later on. Ready? Begin.

John: The system should offer basic RFQ functionality for our buyers.

Facilitator: Ok, good one (writes it on whiteboard).

Susan: We also need a more in-depth set of RFP functionality.

Facilitator: Ok, very good.

Roger: But aren’t those things sort of the same thing?

Facilitator: Maybe, maybe not. Let’s focus on gathering the rest of the requirements, then we’ll discuss the merits of each of them in turn.

Jane: We’ll need a news portal.

Facilitator: Got it.

Jane: And we’ll also need an online supplier directory.

Facilitator: Very good. Let’s keep going. Faster, if we can.

John: Permission marketing.

Susan: Invoicing and billing.

Randy: Broker integration.

Roger: Contract management.

Facilitator: Great! Let’s keep those ideas flowing!

and so on …

If you get the team working in a rapid-fire mode, you will be completely amazed at the sheer number (and quality!) of ideas that come forth.

As a footnote here, it may be helpful to have the team “practice” a brainstorming session first. First, pick some arbitrary inane topic. For example “the best way to hand wash a car,” or “we are building a house, let’s talk about what features this house needs to have in it.” Allocate 5 minutes to the brainstorming session, and let them go through it. This is a good ice-breaker as well. Give them some feedback on their brainstorming techniques at the end, and then move into the real session.

Once the time limit has expired (the time limit is completely arbitrary, although I recommend keeping it to 10 or 15 minutes at the most), and you have “broadly” captured the first round of requirements, it is then time to examine them in turn. Of course, anything the group feels is out of place, or nonessential, can be easily removed from the list.

Frankly, the easiest way to examine the requirements is to simply ask the group to comment openly on the generated list. Most of the time, they will logically begin funneling similar requirements into broader groupings, which is the ideal scenario. For example, RFQ, RFP, and contract management functionality might all end up in a bucket called “transactional requirements.” Things like “receiving” and “shipping” could be logically grouped into a broader “logistics” category. It is up to the group, through your leadership, to determine what the best number and type of categories to use.

Ultimately, you want to have a nice list of 5-10 (or even a dozen) high level areas, with each of them having perhaps a few sub areas within them. Once you’ve done this, you should start a second round of brainstorming. This time, however, the goal is to provide ideas around the current list of functional areas. We do this for several reasons, but the primary reason is that by seeing the list up on the wall, the participants will naturally begin to expound upon those ideas, and come up with even newer ones … or things that perhaps were overlooked in the first round of brainstorming.

Once this 2nd round has concluded, you should again lead the group through an open discussion of the requirements. Again, the priority here is to streamline the list – grouping and removing as needed. You can theoretically repeat this process any number of times, although generally speaking, 2 or 3 times is sufficient.

Once you’ve done this, you should now be in possession of the broad, high-level requirement areas for this system. You are now ready to move into the prioritization phase. We will brainstorm the detailed requirements shortly, but for now, let’s focus on the the high level requirement areas.

Remember in the previous article where I mentioned that having several thousand dollars in fake money would come in handy? Well, we’ve arrived at that discussion! There are lots of ways to lead a group through a prioritization exercise, but I am partial to what is known as the “$20 method”. In this model, the facilitator gives each participant $20 in singles. You can also do this without using actual physical fake money, but it is more fun to do it this way. Each participant can “spend” their $20 on whatever functionality they desire. The more money they spend on an area, the more important that area is to them. At its core, this is a simple exercise in “weighting”.

If John spends $8 on “logistics”, and $3 on “transactional functionality”, then that means John places a higher value on the logistics functionality within the newly proposed system. At the end of the exercise, it is interesting to see what areas people spend their money on. Often times, their areas align politically with their vested interests – so keep this in mind.

As you can see in this partial screenshot of our Excel model (click image to expand), the business side of the equation was represented by three people (John, Susan, and Mike). The technical team had 4 members present (Jeff, Roger, Jane, and Jill). They each spent $20 on the various high-level functional areas (Transaction, Workflow Management, etc.) You can also see some additional statistics to the right, such as simple summations and averages. Of note are the color coded cells to the far right, which indicate which control group favored a particular area – for instance, the technology team spent more money (on average) on Workflow Management than the business team.

I should point out that all of the functional areas are “important” if they’ve made the final list. Just because one area doesn’t get as much attention as the others, doesn’t mean it isn’t critical to the system. It is also important to point out that the final functionality matrix is not necessarily set in stone. Even though we’ve applied some basic statistical methods to capturing, grouping, and prioritizing the requirements, in the end, the business drivers may screen that a certain requirement be bumped up the list, or bumped down. Common sense, of course, should prevail. The functionality matrix is simply a streamlined viewpoint into the system requirements.

The same weighting method can be applied to the requirements under each major category. I generally use a separate Excel sheet for this. As you can see from the screenshot below, the four requirement areas under the larger “transaction” category are also prioritized.

You’ll also notice that at the top of the sheet, there is a small decision matrix. This four quad matrix compares technical complexity on the vertical axis, and business benefit on the horizontal axis. The four quadrants break down as follows:

• Upper left quadrant (high technical complexity, but low business benefit): Definitely not in phase one
• Bottom right quadrant (low technical complexity, but high business benefit): Definitely in phase one
• Lower left quadrant (low technical complexity, and low business benefit): Examine options – Risk averse approach
• Upper right quadrant (high technical complexity, and high business benefit): Examine options – Risk taker approach

Hopefully, this is self-explanatory. The idea is to figure out which quadrant each subfunctional area falls within. To do this, we need to establish some cutoff values. At the top left is a smaller version of the matrix with “cutoff” values in it. These values represent the cutoff values that affect the conditional shading of the cells in the main content area. The idea is that you should be able to quickly scan the content area to see which functional areas fall within each quadrant of the decision matrix. For example, the “contract management” functional area (under the larger “Transaction” category) has a business benefit value of 47.92%.

We got that by taking the average for that line item (10.00 + 8.75 + 10.00) and dividing that number by the total points spent (20, as in $20). That gives us a simple percentage. 47.92% of the business teams money went into the “contract management” functional area. Since our cutoff value is 30%, the shaded color is green (which according to the decision matrix, would indicate that the business folks feel that this functional area should be in phase one of the system). This area clearly has a high business benefit!

However, the technical team’s score is 45.83% – which is over the cutoff value of 25%. This means that developing this functional area will come with a high level of technical complexity (meaning risk!).

So now we have a situation where both sides of the equation (business and technology) feel that this area has a high value. This would push us to the upper right quadrant (shaded yellow). I know this all sounds a bit complicated – and it is. But hopefully this all makes some sense to you.

This post has run a bit long (okay, way long.) I will save the final bit (where we dive into the detailed requirements and finalize things) for another post. I’ll also provide some Excel templates for you to use as well.

Cheers, and happy JAD’ing!

Abstract: This presentation will include an introductory explanation on the theory and history of Model Driven Architecture (MDA) and an overview of its major underlying components, including an initial discussion on the Unified Modeling Language (UML) to establish a baseline understanding for the audience. We will highlight the various stages of an MDA approach and will emphasize the impact MDA can have on the software development lifecycle. Specifically, in regard to an organizations ability to deliver high-quality, reusable software within a repeatable process while significantly reducing project risk and increasing return on investment.

We will follow this discussion with a practical demonstration of MDA techniques to illustrate these principles and concepts. We will discuss the pros and cons of MDA, the state-of-the-art, and the steps required to leverage MDA in your existing business environment. We will end the presentation with a brief question and answer session.

Speaker Bio: Robert Lario is a principal and co-founder of INHERIT, LLC. He has over 20 years of software development experience designing, developing, and deploying enterprise solutions using Object-Oriented techniques. He has a Masters in System Engineering from the University of Pennsylvania and an MDA from the Wharton Business School. Based on years of practical experience, Mr. Lario began development on Inherit Express MDA tool in 1998. He has been the primary architect and the driving force behind the development of each release, including the most recent version Express Templates. With his work on INHERIT Express, Mr. Lario is leading the evolution of the state-of-the-art of MDA

If you are in the Atlanta area, the meeting will be held in the Oracle office at Northpark Town Center (building 500, suite 1120). Check the Atlanta SPIN web site for the latest details and directions. Come out for some great networking with some of Atlanta’s top software development professionals. The free pizza is a bonus!
http://www.atlantaspin.org

See you there!

Cheers.

Abstract: All organizations measure some aspect of their performance, with the goal of managing and improving their processes and products. Unfortunately many organizations get bogged down in the measurement process – developing too many measures (or too few), overly complex implementations, failing to use metrics for improvement initiatives, or failing to link metrics with top-level strategies or actual work processes of the employees. This session will provide you with real strategies and implementation insights necessary to set up and sustain a measurement system for monitoring and improving your IT organization. Key to any measurement program is the ability to view progress in real-time. Thought leaders in the industry are turning to management dashboards as a way to gain clear visibility of project status, processes and metrics across the enterprise. While most organizations possess many sets of metrics, a re-evaluation and re-examination of what exactly is being measured and how it is being reported and used is key.

Specific topic areas will include:

• Collecting data that is linked to the business objectives of your organization
• Engaging all levels of your application development and IT functions to participate
• Setting up a management dashboard and relevant reports
• Using data and metrics proactively for continuous improvement

Speaker Bio: Mark Schadt has over 23 years of experience in Application Lifecycle Management processes and solutions. His areas of expertise are process/workflow assessment, design and management, as well as the implementation of management systems for version control, software configurations, build and deployment, requirements, and geographically distributed development. Prior to joining MKS, Mark worked for IBM Rational, Apple Computer and Texas Instruments, and as an independent software change management consultant he advised companies such as AT&T, Time Warner, TRW, and Lockheed Martin. Mark has a Masters degree in Computer Science.

If you are in the Atlanta area, the meeting will be held in the Oracle office at Northpark Town Center (building 500, suite 1120). Check the Atlanta SPIN web site for the latest details and directions. Come out for some great networking with some of Atlanta’s top software development professionals. The free pizza is a bonus!
http://www.atlantaspin.org

See you there!

Cheers.

As promised in my post on IT Facilitation Skills, this article will take a more “hands-on” look at conducting JAD workshop sessions. While there is no single “best” way to accomplish JAD objectives, I will try to present a format that has worked nicely for me in the past, in the hopes that it will give you some ideas as to how best to structure your own sessions.

JAD (Joint Application Design), is a software design process which attempts to bring together various business stakeholders (most likely users) and IT professionals in a highly focused workshop environment. Why do we prefer this format? Well, in the old days (gee, all of 10 or 15 years ago) most sets of functional requirements were cobbled up by business analysts and “tossed” over the wall to the software engineers, whereupon we were supposed to plop a handful of arcane ingredients into a big pot, mutter a few incoherent passages from Ken Thompson’s UNIX Philosophy and stir until some magic software solution poofed out of it. Alas, the road to JAD is paved with the morasses of projects past that have stemmed from poor requirements gathering.

Of course, the problem with this is obvious – business analysts are generally not technologists, and vice-versa. Business personnel are not necessarily adept at taking into account technical constraints/limitations, best practices, or the newest innovations. Likewise, technologists have not historically been overly proficient at cobbling together business requirements. It has been unequivocally proven that by bringing both sides of the house together to define the requirements that a vast majority of common problems and misunderstandings can be dealt with up front (where they cost $1,000), rather than in the 47th week of the project (where they cost $1.3M).

Make no mistake, JAD is not the panacea for software development, or even requirements gathering, for that matter. It can, however, provide a pretty good path of least resistance. Theoretically speaking, the big advantage of JAD is accuracy, or the ability to deliver a system with the functionality that is actually needed. In addition, JAD affords you with a dramatic shortening of the time it takes to complete a project (due to having tighter functional specs up front). Of course, your mileage may vary – I have found that having a very experienced facilitator goes a long way toward determining the eventual impact of the session(s). The use of JAD also improves the quality of the final product by focusing on the gathering of accurate requirements, thus reducing the likelihood of errors that are expensive to correct later on.

Much of this information is taken from “consulting 101″ – if you have some business background, a lot of the initial concepts may be familiar to you. But keep reading – we’ll get vertical soon enough. I apologize in advance for this article’s length, but I don’t believe in “blogging for blogging’s sake.” I prefer my blog entries to have substance and value. I hope you will agree!

Workshop Preparation

As any experienced facilitator will tell you, quite a bit of the work effort you will put in will occur well before the sessions even begin.

The very first thing that the facilitator needs to do is to ensure that he/she fully understands the context of the business problem being addressed. Note that I did not say that “granular industry knowledge” was necessary, nor did I mention anything about the facilitator having technical prowess. The focus here should be on understanding the context of the business problem.

What is the problem we are dealing with here? Who is affected by it? What are we trying to accomplish. What stakeholders will be affected by this system, and how many of them will attend the session(s)?

Once you have a grasp of the breadth of things, you will be in a position to direct the subject matter experts to drill down vertically into the problem. Interviewing various stakeholders is a good way to cobble up the knowledge that you need – this can usually be done pretty quickly.

Don’t be surprised, however, if you get to day one of the session and realize that you overlooked an important aspect of the group dynamic or the business problem. This can (and will) happen. Just prepare yourself as best as you can up front, and be prepared to augment that knowledge with things you pick up on-the-fly during the session.

As far as physical, tangible items goes, here is a list of items that I have found to be helpful during a JAD session:

1. Large whiteboard (preferrably mounted on wall), markers, eraser
2. Large Post-it style easel pads
3. Projector (for use with workshop slides)
4. Laptop with Microsoft Office suite (Word, Excel, etc.), or some other set of tools (Corel Office, Appleworks, Lotus Smart Suite, OpenOffice/StarOffice, etc.)
5. Several thousand dollars in fake money (I’ll explain later – ha!)

Workshop Agenda

As a starting point, I like to break down requirements gathering into two distinct phases – both phases consisting of facilitated JAD sessions. In the first JAD session, we will gather very high-level requirements and funnel them into what I call a prioritized functionality matrix. In the second session, we take that functionality matrix and generate draft use-cases from them.

For the first session, which I think is the most critical, I tend to follow a high-level agenda similar to the following:

• Introductions:
• Session Roles
• Ground Rules
• Objectives
• Reaffirm:
• Vision
• Business Drivers
• Business Context
• Baseline Functionality Matrix
• Wrap up

We will discuss each of these items in more detail below.

For the second session, the agenda would look something like this:

• Quick Review of Functionality Matrix
• Use Case Mini-Tutorial (to educate the stakeholders)
• Use Case Identification
• Draft Use Cases
• Wrap Up
• Questions
• Next Steps

NOTE: We’ll cover the detailed creation of the functionality matrix and use cases in separate articles.

Session Roles

Before beginning your session, the facilitator should work with the various stakeholder participants to identify those individuals who will fill certain critical session-specific roles. These roles are discussed briefly below, but it is incredibly important that these people be identified in advance, and are not surprised by their assignments on the day of the session!

The Facilitator: This is the easy one. This is the person leading (facilitating!) the session. For more info, see my article on IT facilitation skills.

Timekeeper: Simply put, this person is responsible for watching the clock and alerting the facilitator when sessions (or segments of a session) are approaching the pre-determined cutoff point. For example, the facilitator may decide to give the group 5 minutes to brainstorm solutions to a particular problem. The timekeeper might alert the facilitator when the clock hits 4 minutes (1 minute warning), and then once it hits the 5 minute limit. This can be done silently by a nod of the head or raising of the hand, or even verbally. Maintaining adherance to a time schedule will help keep people focused, and assist in keeping things rolling along.

Scribe: Outside of the facilitator, this person probably has the most instrumental role in the success of a session. The scribe is essentially the secretary – they keep track of all major outcomes of the session. This is similar to meeting minutes, but is more detailed. This can be done via pen and paper, but in most cases, it is probably best done on a laptop, where the person can switch around between Excel, Word, and other applications. Depending upon the makeup of the stakeholder groups in the room, this person may also be the one responsible for drafting the functionality matrix (in real-time, with input from others).

Parking Lot Attendant: Invariably, things are going to arise that are out of the scope of the session’s guidelines. In order to keep from getting off track and derailing the session, the facilitator may reserve the right to “park” those issues or questions in the “parking lot” so that they may be addressed later. I generally like to address the parking lot issues list at the end of the session (or at the end of each day, if the session will span multiple days).

SMEs/Participants/Devil’s Advocates: Everyone in the room, including the people filling the roles above. Remember, the more valued input you have, the more productive your session will be!

You may decide to come up with other ancillary responsibilities and roles – this is your discretion as the facilitator. Just be careful not to over-delegate to the participants – you want the principal parties to be focused on the task at hand, and not immersed in some other duties that will detract from this.

A Bit on Brainstorming

For those of you who may be new to the concept of brainstorming, I will simply refer you to the great entry over at WikiPedia. However, I will state that I am a big fan of whiteboards, and an even bigger fan of the big Post-It easel style pads. Those are great for capturing ideas quickly, ripping them off, sticking them on the wall, and moving along to the next idea.

Ground Rules

It always pays to lay out the ground rules up front, so that everyone is on the same page from the beginning of the session. What these rules are, in the end, is up to you as the facilitator. In general, I like to use these as a starting point:

• Stay focused
• Be honest
• Respect opinions
• Stay on time
• Use the parking lot
• Brainstorming rules
• There are no bad ideas
• No criticism of an idea
• Strive for quantity, not quality
• Strive for creativity, think out of the box
• Build on the ideas of others

After I explain these rules to the group, I generally ask if anyone else in the room has any other ideas for ground rules to add to the list for the session. Occasionally, someone will throw something out there (no checking email during the session, turn off cell phones, etc.). Calling for other ground rules is a great way to begin empowering the participants, and to set the tone for the session.

Objectives

Once the session roles and ground rules have been announced, I like to immediately state what the official “objectives” of the JAD session are. You would be amazed on the first day at how many people actually proclaim things such as “oh, I thought that JAD meant we were going to build the application together” or “I thought we were just going to talk about the need for the project, I didn’t know we were designing it!” The objectives I usually use as a starting point are:

• Define the system scope
• Draft use case models for primary scenarios
• Define the domain model/glossary

The “system scope” is going to be defined largely by our functionality matrix (deliverable from the 1st session), whereas the use case models and domain model/glossary are going to be outputs from the 2nd session.

You may feel the urge to add additional objectives to this list. My only advice to you here would be to make sure to tie any new objectives to specific deliverables that will come out of your session(s).

Reaffirmations

I like to go through a series of “reaffirmations” before I lead the group into unchartered waters. I want everyone in the room, from the lowliest coder to the most senior executive, to understand why we are building this product, who it will affect and benefit, and what value it will bring to the market or stakeholders.

Reaffirming the vision of the project is first on the list. The “vision” could be anything, really, but it should be related in some way to the project. If your organization is following a PMI style project plan, then this is probably the project charter. If you are building a software platform for a startup company, then this is probably the actual vision statement of the company itself.

Next, I like to reaffirm the business drivers and business context. Why are we doing all of this again? What business problem will this project solve? How big is the market we are talking about here? What is the value proposition?

Let’s state all of this as a matter of fact – level the playing field by educating (or-re-educating) everyone in the room.

Critical Success Factors

At this stage in the game, we really haven’t done anything toward the actual design of the system. This is a good thing. All of this groundwork will serve us well as we move further into the process.

After the reaffirmations, I like to do a quick 5-10 minute brainstorming session where the group throws out potential critical success factors (CSFs). This allows the stakeholders to identify very succinctly those things that will make or break this project or product.

Consider these examples:

• Head of Marketing: “It is imperative that we have 24×7 uptime – availability will be critical to our customers!”
• Lead Developer: “We should implement this system using an open architecture in order to easily integrate new technologies or functionality in the future.”
• Business Analyst: “It is important that we have executive buy-in and participation from our key industry design partners.”

You get the idea. Don’t camp out in this stage – this should be quick, but also helpful in setting everyone’s expectations and understandings.

Current Processes (As-Is) / Future Processes (To-Be)

Once we’ve identified the CSFs, I like to do a very brief “as-is/to-be” analysis. This may or may not be something that every project will use, but I do find them useful in two cases. If you are designing a new product (or working with a startup company), then the “as-is” will probably represent the current state of the industry. If you are doing business process reengineering, and your software product will be a part of the future processes, then the “as-is” will probably represent the current business environment.

In either event, the questions you will ask will be the same:

• What are the major flows of information?
• Who is involved?
• How are stakeholders doing business now?
• What do those processes look like?
• What technologies do they use?
• What tools do they use now?

Additionally, in either event, the “to-be” part represents the deliverables/outcomes of the project itself.

Why do we spend time on this? I have found that if all of the stakeholders, including the development team, have an understanding of where we’re going, and what things look like in the current state of affairs, the end result is a much more cohesive and functional product.

I usually spend 45 minutes on the “as-is” area, and another 45 minutes or so on the “to-be” area. I would recommend a break in between!

Assumptions

Getting weary yet? Don’t fret, as we’re nearly done with laying the groundwork! Only one last item remains. The final area that I like to touch on before leading the team into the design process is the generation of relevant assumptions. These are generated via a short (10-minute) brainstorming session. These should represent things that the project design team are assuming to be true, or in place. Generally, they represent inputs to the system, or owners of certain things. I like to brainstorm these up front, so that the group doesn’t keep disclaiming things all throughout the session.
Examples:

• “Our major design partners will be responsible for content management within the product catalog.”
• “The initial database content will be provided by Acme Corporation, one of our key partners.”
• “Marketing will provide a list of 10 qualified beta customers before we launch.”

One caveat here. If you sense that the group is starting to “haggle” or argue over the assumptions, then they apparently are not assumptions to begin with. In such cases, either choose to put the issue in the parking lot, or make a note to revisit it at a later time during the session, where it can be discussed in a more streamlined manner.

Functionality Matrix

Congratulations, you’ve made it through all of the groundwork exercises. We’re ready to begin taking all of the information from the brains of the participants and funneling them into a prioritized functionality matrix.

The functionality matrix is essentially a prioritized grid of the major functional areas within the proposed system. The matrix can be developed using whatever tools you wish, although I recommend Excel, as I find its ability to do quick calculations for me (important later on) and conditionally formatting cell colors to be handy.

However, given the sheer scope of what is involved in creating a functionality matrix, I will save it for a separate article. Don’t worry, that article has already been written – it will publish a week from the date of publication on this article, so be sure to check in then for a more detailed walkthrough. In that article, I’ll also share with you the reasons for bringing several thousand dollars in fake money to your JAD session. :)

Wrap-Up

Hopefully, the functionality matrix came together in short order. Even the most demanding set of requirements should be able to be pulled together in no more than 2 days (but most often in an afternoon). Don’t forget to address any issues that were plopped into the “parking lot” before going home!

Next steps: Use Cases

Let the participants know that all of their hard work is about to be funneled into the next phase, where the individual use-cases will be developed. These will provide the “substance” behind the functionality matrix.

My final thoughts

I know this was a lot of information, and if you’ve made it this far, then I commend you! While I think all of these ideas are a fantastic way to approach your JAD sessions, I would like to say again, however, that these are not the only areas that you can explore. Use your imagination! Every session will be different, because every project is different. Just follow your instincts, and I’m sure you’ll do fine.

In order to make things a little easier for you, I am including a bare-bones Powerpoint presentation that lays out the flow of this type of JAD session (coming later this week!).

Cheers, and happy JAD’ing!

As Napoleon Bonaparte once quipped, “there is somebody wiser than any of us, and that is all of us.” Gathering functional requirements is a fundamental part of any software development methodology, yet many IT leaders seem to avoid honing their facilitation skills, something I consider to be a critical tool in this process.

IT leaders spend quite a bit of time (hopefully) focusing on process improvement and methodology. They spend a substantial portion of their time focusing on things such as Six Sigma, Agile, waterfall, RUP, SCRUM, eXtreme Programming (XP), and and a host of other silly-sounding names. However, even the most robust software development methodology will not save a project wherein the requirements have not been adequately defined. The process of facilitation is the linchpin on which the vast majority of current IT buzzwords and acronyms solidly relies upon, therefore it is in the best interest of the modern IT leader to examine and refine this aspect of their responsibilities.

Additionally, we hear so much buzz about IT leaders who can “bridge the gap” between the business drivers and the technology which brings it all to life. Sadly, too many people throw this jargon around loosely, without realizing that ramping up one’s facilitation skills is one of the best (and easiest!) ways to achieve this.

Facilitation is described by the Merriam-Webster dictionary as simply “to make easier” or “to help bring about.” The act of facilitation in a business context generally refers to the process of designing and running a successful meeting of some sort.

Specifically, facilitation concerns itself with all of the tasks needed to run a productive and impartial meeting, while serving the “needs of the group”. In the real IT world, the “needs” of the group will most often focus around some sort of business objective, such as gathering functional requirements for a software project or determining the best place to install a new data center. Typically, this is done by conducting a JAD requirements gathering session. I will most likely address the area of how to actually conduct a JAD session in a later article. In this piece, however, I’d like to spend our time sharing my thoughts on facilitation “soft” skills themselves.

Taking the lead in this process is the facilitator, whose primary job is to create and maintain the proper circumstances for discussion. In addition to monitoring and enforcing the discussion rules, the facilitator must make a decision every time a participant speaks. What do I say next? What if this current idea runs to a logical conclusion? Where will we go next? Should I call on another person to provide an alternative viewpoint? Should I stop this person from dominating the conversation? And so forth.

At the end of the day, the facilitator can choose to ask questions of the participants, make statements concerning the progress of the session, or simply remain silent. Questions are asked for the obvious reason. By asking questions, the facilitator is able to elicit responses, redirect the conversation (if it is going into a nontargeted or unproductive area), or to help the participants clarify, elaborate, or justify their statements.

By making statements of their own, the facilitator is able to invite questions, share thoughts, or to summarize things that have been said during the session (which benefits everyone). I can’t tell you how many times that potential problems have been avoided by the facilitator simply attempting to restate what has been said. It’s like that old game where you say the same thing to a room full of people, and ask them to then write it down. You always seem to end up with a variety of twists on the same story. It is probably meaningful if everyone understands that we are expecting to process 10,000 transactions a day from 100 customers, rather than 10,000 customers with 100 transactions each.

Perhaps the most important aspect of being a good facilitator is the concept of neutrality. It is imperative that the facilitator remain a neutral party throughout the lifetime of the session(s). As you can imagine, this is not always an easy thing to do, especially if your development team is on one side of the table, and your business leaders or clients are on the other. Nevertheless, be sure to introduce yourself at the beginning of the session, clearly define your role up front, and make an explicit agreement with the group that you will make every effort not to manipulate the discussions or become embattled at the detail level.

The group must have the understanding that you are there to serve them. If this trust level is breached, then the validity and integrity of the session could be in jeopardy. Don’t hesitate to ask the group how you are doing from time to time. Are things moving too slowly? too quickly? Are the discussions remaining on-topic, or can you do a better job keeping things together? Don’t get me wrong, you don’t want to do this at the end of every segment. However, there is certainly nothing wrong with this practice, and it will reinforce for the group your sense of command, accountability, and desire to remain neutral.

Verbal involvement on the part of the facilitator is used to keep the discussion moving along its intended path. The level of verbal involvement by the facilitator will vary from one session to the next, due primarily to the changing needs, personalities, and group dynamic of the participants. However, the facilitator should be careful to balance his/her verbal participation with that of the group. If the facilitator is talking too much, then chances are, not enough content is flowing into the discussion from the relevant parties, and the right opinions are probably not surfacing. If the facilitator sits in the corner and says very little, then the session runs the risk of spiraling out of control, with off-topic discussions, lack of consensus-building, and so forth, eventually devolving into a full-fledged goat rodeo.

So how do you strike the right balance of verbal involvement? For starters, the facilitator should listen closely to the participants, and ensure that they are listening to each other. This will have the desired outcome spurring on conversation. Unless your participants are openly communicating with one another, then the session is a bust.

It is possible that not everyone in the room will want to participate. I recalled this one particular JAD session that I conducted a few years back within the radio industry. One of the stakeholder groups represented in the session were some folks whose jobs would be eliminated by the software solution we were designing. Suffice it to say, they weren’t necessarily forthcoming with ideas during the meetings.

Nevertheless, as a facilitator, you should encourage each participant to contribute to the dialogue. In situations where you have potentially adversarial groups in the room, you may need to take measures to protect certain participants from personal criticism. You may also need to prevent the focus from being on personalities, and concentrate everyone’s attention on the issues at hand.

Occasionally, the facilitator may walk into a situation where he or she needs to protect the group from one person’s dominance, or the dominance of a particular faction within the room. This is especially critical, given the overarching goal of soliciting as many ideas and as much feedback as possible, from all stakeholders in the room. In extreme instances, the facilitator may need to pull the offending person(s) aside during a break, and discuss the need for other views to be heard. Generally, though, this sort of thing can be avoided by simply calling out to other people in the room, to give them a chance to be heard.

Sometimes, you may sense that a particular person or stakeholder group is not being as participative as you’d like. These “silent” players often hold the key to breaking through an impasse, or bringing the convergence of ideas to life. Many of them want to be heard, but lack the courage, or desire to speak up on their own. You should respect their silence, but only to a point. After all, if a stakeholder is just sitting in the room and not adding value, then it is a wasted seat. The facilitator should provide logical “openings” for such people to insert themselves into the discussion. If you sense that someone has something to say, but for whatever reason, is biting their tongue, call ‘em out gently, and see where it takes you.

Remember to be an energizer for the discussion. Get ‘em fired up. Hopefully, the participants are all there to find help in solving problems or addressing the issues at hand. They are relying on you, as the facilitator, to assist them in navigating the waters and obstacles that lie ahead. If you lead by example, and set a positive tone for them, your session should go smoothly.

Click here for part two in this series: JAD Facilitation Workshop Basics
Cheers, and happy JAD’ing!

The topic will be “Still Searching For the Silver Bullet: Pitfalls of RAD, Agile/XP and Other Forms of Iterative Development”

Abstract: In our never-ending search for faster, as well foolproof, ways of doing development, we continue to chase after promises that often fall short of expectations. Come hear Lois Zells give a brand new presentation about the project management pros and cons of RAD (Rapid Application Development,) Agile/XP, Evolutionary Development, Iterative Development, and Prototyping. Hear the latest on why these types of projects are still failing and how to avoid the pitfalls. Have a common sense discussion of how to manage realistic expectations before projects go awry. This session is apropos for all levels of the IS organization from analyst/programmer to CIO, from business unit user to business unit project participant, from project lead to program manager, albeit technical or non-technical..

Bio: Lois Zells is an international author, lecturer, and business consultant, specializing in software engineering consulting. A popular speaker at European and United States conferences, she has spoken at the American Society for Quality Control, The Quality Assurance Institute, the Association for Computing Machinery, the Institute of Electrical and Electronic Engineers, the Cap Gemini Institute, the Association for Systems Management, the Berlin COMPAS Expo, ComputerWorld Germany Software Forum For Europe, PC Expo, Cap Gemini London, Technology Transfer Institute America, Technology Transfer Italy, IBM’s Users Groups: Guide and Share, the Data Processing Financial Management Association, the Canadian Information Processing Society, the Project Management Institute, the Data Processing Management Association, the Federal Computer Conference, the Structured Development Forum, the Structured Techniques Association, the National Computer Conference, the AFIPS Office Automation Conference, the Year 2000 Conference & Expo, and Brainstorm Group’s Y2k Conference.

Ms. Zells is the Co-founder and Past Executive Advisory Chair for the 20,000-member Information Systems Specific Interest Group of the Project Management Institute, a worldwide organization of 80,000 plus members. She was honored as a PMI woman of the Year in 1993; and is co-honoree of the PMI Wilson/Zells Scholarship Fund.

Because of her acknowledged expertise in software engineering and project management, Ms. Zells frequently serves as an expert witness in multi-million dollar software litigations. She has also served as an examiner for the Arizona Statewide Baldridge Award and served for several years on the review committee for the revision of ISO 9000-3 (International Standard ISO/IEC 12207.)

Ms. Zells was also on the Advisory Board for PC Expo, one of the two largest PC conferences in the world. She has also served on the Board of Governors of the Brainstorm Group. Ms. Zells is the author of (and consultant in) several popular management workshops in strategic planning, project management, total quality management, strategic systems planning, process maturity assessments, systems development methodologies and techniques, business process re-engineering, and systems maintenance.

She has authored the best seller, “Managing Software Projects” and has published many articles in the major periodicals of the industry. For several years, Ms. Zells was a contributing editor for “Application Development Trends.” She is also the developer of the Total Quality Management seminar series “Software Excellence Through Total Quality Management.” Her most popular seminar series is the totally-integrated, three-tier learning program on software engineering project management called “Successful Projects: The Common Sense Approach.” Ms. Zells has written the introductory chapter for “Total Quality Management for Software,” published by Van Nostrand Reinhold and the information systems chapter for the AMA’s “Program and Project Handbook.” She is now also working on her second book: “The Practical Guide To Successful Projects.”

Ms. Zells has been a significant contributor and participant in a long-range strategic planning innovation search—sponsored by the Advanced Systems Concepts Office of the U.S. Army Information Systems Command and jointly managed by SRI International and Mandex, Inc.

Ms. Zells’ other clients range from the Fortune 100 firms to new start-up ventures and are spread across a broad array of industries. She has worked with a large international computer manufacturer, a major international steel manufacturer, several large nationwide insurance companies, an international telecommunications company, a major food processor, a large health-care provider, a major aerospace manufacturer, and two international electronics firms—in helping them to turn around and improve their software engineering processes, by defining their requirements for achieving software maturity and creating an environment conducive to successful high-quality projects, by also developing their software engineering and project management programs and seminars, and by consulting on several significant projects.

Highly specialized in Structured Analysis, Structured Design, and Structured Programming, she taught these subjects for five years at Phoenix College as well as for three and a half years with Yourdon, Inc. (an international seminars/consulting firm), where she also developed their popular project management curriculum, the Project Planning and Control Workshop. During this time, she was personally trained as a disciple of Ed Yourdon, Tom DeMarco, and Tim Lister: the leaders in the field. She has also used the structured techniques and various CASE tools on many projects that she either participated in, consulted on, or managed.

Ms. Zells graduated Summa Cum Laude in Data Processing Management from the University of Baltimore and did her master’s studies in Computer Sciences at Johns Hopkins University and Arizona State University.

Having served as consultant, department manager, project manager, systems analyst, operating systems programmer, and applications programmer/analyst, Ms. Zells has over twenty-five years in data processing. With many years of job-related experience in hospital applications, manufacturing applications, banking and finance, and with also 17 and 1/2 years in systems management consulting for the banking, insurance, and manufacturing industries as well as the government, she has managed the implementation of an in-house end-user time sharing company, office automation, strategic systems planning, business process re-engineering, a multimillion dollar client/server processing system, an interactive project control system, an automated teller machine network, a 100 station local and remote distributed customer information and network switching system for charge card data entry and authorizations, entree into charge card duality for MasterCard and Visa, and a patient billing system.

Ms. Zells has also managed the development of standards in project management, programming, documentation, change management, planning, prioritizing, and quality control. She has developed project estimates of time, resources, and dollars for small projects with a few hundred tasks to large projects with many thousands of tasks. Ms. Zells has worked extensively with a telecommunications company in helping them to turn around their declining business position by guiding them through an innovative strategic planning process and then repositioning their product distribution channels.

Ms. Zells has presented seminars in systems management for the personnel department of a large state agency, so that they could rewrite their existing job descriptions. She has also served on a federal government committee that was established for the purpose of evaluating job classifications as well as to aid in enlisting and keeping exceptional workers in government.

Publications

Ms. Zells is the author of (and consultant in) several popular management workshops in strategic planning, project management, contingency planning, litigation planning, total quality management and quality assurance, MIS planning for the corporate executive, software process maturity assessments, product development, business process re-engineering, selecting and implementing systems development methodologies and techniques, managing client-server development, managing emerging technologies, and systems maintenance.

Her most recent efforts include the new Managing Emerging Technologies and the Total Quality Management seminar series Excellence Through Performance and Excellence Through Total Quality Management. She has also authored the popular, totally-integrated, three-tier learning program on software engineering project management called Successful Projects: The Common Sense Approach.

She has authored the best seller, Managing Software Projects: Selecting And Using PC-Based Project Management Systems published by QED Information Sciences. Ms. Zells has written the introductory chapter for Total Quality Management for Software, published by Van Nostrand Reinhold and has contributed a chapter on Information Systems Project Management to The Program and Project Handbook, published by the American Management Association.

She has contributed to and published many articles in the major periodicals and proceedings of the industry such as Investor’s Business Daily, ComputerWorld, the National Computer Society Proceedings, the PMI National Symposia, PMI’s PMNet Journal, The Structured Techniques Association, ProjExpo, ACR’s Managing System Development, IEEE’s Software Process Improvement Conference Proceedings, The Federal Systems Journal, and Application Development Trends.

http://www.atlantaspin.org

See you there!

Cheers.

Abstract: The last few years have seen an explosion in the number of reference models an organization might use as the basis for improving its performance. Notwithstanding the Software Engineering Institute’s efforts to consolidate reference models in the Capability Maturity Model Integration (CMMI), the number of models has continued to grow. An organization wishing to use best practices to establish “world class” or “best in class” performance faces a bewildering array of choices. IT shops may consider not only the CMMI, but also be thinking about COBIT, ISO 90003:2004, ITIL, and PMI’s Organizational Project Management Maturity Model (OPM3), to name several of the more widely used models. Faced with such an array of choices, many are left wondering if these models integrate synergistically. Alternatively, do they represent a huge effort to implement individually, with little relationship to one another. Assuming the latter is true, many face difficult choices, in an environment in which allocation of limited resource is fiercely competitive. This presentation describes an integrated approach to improving organization performance based on process architecture and detailed model mappings.

Bio: Mr. Brotbeck is an Information Technology consultant with over 35 years experience in the areas of business and information technology planning, business process reengineering, software engineering, software process improvement, and complex information systems development. He has expertise in object-oriented technology, software quality assurance (QA), seminar and workshop development and delivery, and management responsibilities ranging from project management to “C-Level” senior line management. Mr. Brotbeck is a Certified Software Quality Engineer, a Six Sigma Green Belt, and an authorized Instructor for Practical Software and System Measurement (PSM). He holds B.A. and M.A. degrees in Mathematics. He is currently an SEI Candidate Instructor for the Introduction to CMMI class, and an SEI Candidate Lead Appraiser.

If you are in the Atlanta area, the meeting will be held in the Oracle office at Northpark Town Center (building 500, suite 1120). Check the Atlanta SPIN web site for the latest details and directions.

http://www.atlantaspin.org

See you there!

Cheers.

Abstract: If loyal customers are the essence of what makes companies successful, why is it that so many organizations fail to involve their customers when developing software products? Depending on which analysts’ reports you read, between 60% and 90% of all new product rollouts fail. More importantly, the number one reason for this failure is lack of customer involvement. When we don’t involve our customers throughout the planning and development process we are at high risk of incurring:

• Cost overruns
• Missed opportunities and expectations
• Lost customers
• Failed products and lost revenue
• Since we are aware of these risks, why do so many companies continue to ignore the needs of their customers when it comes to developing and maintaining market-driven products?

What You’ll Learn – Larry Boldt will share with you the importance of having an effective Customer Feedback Management process to ensure that customer’s have a voice in product planning and development. In addition to an effective process, the people and technology aspects will also be discussed ensuring that the process can be implemented successfully.

The Take-Away – Seven habits or behaviors of an effective customer feedback process are provided as a checkpoint for attendees to measure the effectiveness of their customer feedback process.

Speaker Bio: Larry Boldt is an accomplished software engineering manager and developer with over 30 years of experience in managing and providing business process improvement products and services to Global 1500 companies. Larry’s areas of functional expertise include: product management, requirements management, process management, change management, software quality management, and system implementation. As the VP of Customer Management for Orasi Software, he is responsible for product strategy and initiatives supporting customer satisfaction and loyalty. Larry holds a Masters of Science degree in Organizational Management from Maryville University.

If you are in the Atlanta area, the meeting will be held in the Oracle (not Orasi!) office at Northpark Town Center (building 500, suite 1120). Check the Atlanta SPIN web site for the latest details and directions.

http://www.atlantaspin.org

See you there!

Cheers.