Department or Program Name

[SYSTEM/APPLICATION NAME]

TEMPLATE
Joint
Application
Design (JAD)
Session
Workbook
JAD Session Facilitator’s guide

© 2009 Regents of the University of Minnesota. All rights reserved. Page 2

JAD Session Facilitator’s Guide

TABLE OF CONTENTS

TABLE OF CONTENTS .............................................................................................................1

JOINT APPLICATION DESIGN SESSION SAMPLE AGENDA.................................................................1

WHAT IS A JAD SESSION?....................................................................................................2

Meeting Ground Rules.............................................................................................................................2
Attendee Contact List...............................................................................................................................2
Design Sessions Deliverables List...........................................................................................................2
Design Considerations Checklist.............................................................................................................3

PROJECT PROFILE.................................................................................................................5

SYSTEM DIAGRAMS................................................................................................................6

ISSUES LIST.........................................................................................................................8

COMMUNICATION MATRIX.........................................................................................................9

TRAINING PLAN MATRIX........................................................................................................10

SESSION NOTES..................................................................................................................11
JAD Session Facilitator’s Guide

JOINT APPLICATION DESIGN SESSION SAMPLE AGENDA

[Project Name]
Joint Application Design Agenda and Meeting Report
Working Session
Meeting
Purpose
Facilitator
Meeting Details Date:
Time:
Location:
Attendees
 = present,  = planned absence, ○ = not present, = conference call; use bold for names of Decision Makers

Advance Pre-reading Materials:

Meeting Topics Reference Led By Time

Meeting Kickoff
•
•

Project Overview
Review Work Breakdown Structure
(WBS)
•

Design and Planning Brainstorming:

Review and recap issues and action

items:

Summarize and Close

© 2009 Regents of the University of Minnesota. All rights reserved. Page 1

 JAD Session Facilitator’s guide

WHAT IS A JAD SESSION?

The Joint Application Design session is designed to facilitate the basic project planning in a group
environment and fast track the identification and resolution of remaining issues. The JAD session
jumpstart the next phase of the effort by providing clear goals and agreement in a one meeting setting
and with all key players and stakeholders, allowing each department to focus on their issues
understanding the impacts to the entire program. Together, the group can define the full impact of
decisions or actions, agree to the final outcome, and approve steps required for the program and the
project teams to identify needs, assign resources, and address questions impacting multiple
departments.

• Serves as an early form of detailed design and technical planning

• Establishes clear communication and consensus
• Helps the team pull different perspectives into a common understanding
• Identifies what the customer and key stakeholders deem essential for success.

MEETING GROUND RULES

• Set cell phones to vibrate
• Do not use laptops for e-mail during sessions
• Participate actively throughout the sessions
• Provide direct and honest feedback
• Demonstrate mutual respect to all team members and differing points of view.
• Ask questions if you don’t understand. No excuse for not knowing what is going on!
• Provide sufficient background information when presenting or discussing a topic (i.e. issue,
problem, decision or acronyms).
• We will keep this flowing and informal, but limit absences to scheduled breaks
• We will be open and inquisitive – there is no bad question, and all team members have the right
to fully know and understand system processes.
• We will be creative and flexible when looking at how we might accomplish our objectives.
• We will be open to change.
• We will apply the “10 minute” rule to any discussion that is not moving forward, and use parking
lots to track issues.
• We will create a cooperative/supportive environment by finding ways to say “Yes”
• We allow the person speaking to have the floor, no side conversations
• IF YOU DON’T AGREE WITH ANYTHING, NOW IS THE TIME TO SPEAK!

ATTENDEE CONTACT LIST

Name Deployment Teams Phone Location

REMOTE ATTENDEES

DESIGN SESSIONS DELIVERABLES LIST

These Design and Planning sessions have the specific goal of:
• Updating the project Issues/Action Items List
• Generating group approval of an architectural design and solution delivery plan
• Gaining agreement on an approach to deliver a Detailed Design Document (format and type to
be determined) that can be circulated for general review and approval and then be used to
guide functional teams through the migration process, by helpdesk groups to provide technical
support, and by technology delivery teams in the product maintenance and production support
lifecycle.

© 2009 Regents of the University of Minnesota. All rights reserved. Page 2

JAD Session Facilitator’s guide

• Standardizing the group on the approach so each functional area can provide detailed
equipment, resource, and expense sizing estimates within 1 week of the sessions
• Providing group inputs to Resource Requirements with Roles and Responsibilities
• Providing group inputs to Project Schedule and Timeline
• Providing group inputs to the Communications Plan (who should be made aware of what when
and how?)
• Providing group inputs to Training Plan (who will need what training when and how?)

DESIGN CONSIDERATIONS CHECKLIST

This checklist captures common elements that should be present in any design. It is presented here to
stimulate thought, guide brainstorming, and to ensure the design being outlined contains all proper design
considerations:

General

Does the design support both product and project goals?

Is the design feasible from a technology, cost, and schedule standpoint?
Have known design risks been identified, analyzed, and planned for or mitigated?
Are the methodologies, notations, etc. used to create and capture the design appropriate?
If possible, were proven past designs reused?
Does the design support proceeding to the next development step?
Have proper fallback consideration been made?

Design Considerations

Does the design have conceptual integrity (i.e., does the whole design tie together)?
Can the design be implemented within technology and environmental constraints?
Does the design use standard techniques and avoid exotic, hard-to-understand elements?
Is the design unjustifiably complex?
Is the design lean (i.e., are all of its parts strictly necessary)?
Does the design create reusable components if appropriate?
Will the design be easy to port to another environment if appropriate?
Does the design allow for scalability?
Are all time-critical functions identified, and timing criteria specified for them?
Are the hardware environment completely defined, including engineering change levels and
constraints?
Are the pre-requisite and co-requisite software and firmware clearly identified, including
release levels and constraints?
Is each event/activity verifiable by testing, demonstration, review, or analysis?

Requirements Traceability

Does the design address all issues from the requirements?

Does the design add features or functionality, which was not specified by the requirements
(i.e., are all parts of the design traceable back to requirements)?
If appropriate, has requirements coverage been documented with a completed requirements
traceability matrix?

Completeness

Are all of the assumptions, constraints, design decisions, and dependencies documented?
Have all reasonable alternative designs been considered, including not automating some
processes in software?
Have all goals, tradeoffs, and decisions been described?
Has the Risk Plan been modified with any new risks posed by the design?
Have all interfacing systems been identified?
Are the error recovery and backup requirements completely defined?
Have the infrastructure e.g. backup, recovery, checkpoints been addressed?

© 2009 Regents of the University of Minnesota. All rights reserved. Page 3

JAD Session Facilitator’s guide

Consistency

Is the design consistent with its upstream and downstream artifacts?

Does the design adequately address issues that were identified and deferred at previous
upstream levels?
Is the design consistent with related artifacts (i.e., other modules, designs, etc.)?
Is the design consistent with the development and operating environments?

Performance/Reliability

Are all performance attributes, assumptions, and constraints clearly defined?

If appropriate, are there justifications for design performance (i.e., prototyping critical areas or
reusing an existing design proven in the same context)?

Capacity Planning

Are all Service Level Agreements and objectives known and addressed?
Does the design improve productivity?
Is scalability development into the plan and is maintainable?
Is Total Cost of Ownership (TCO) controlled or reduced?

Maintainability

Does the design allow for ease of maintenance?

If reusable parts of other designs are being used, has their effect on design and integration
been stated?
Does the design resist erosion in the correctness of its content over time?

Compliance

Does the design follow all standards necessary for the system? (i.e., date standards)
Have legal/regulatory requirements been assessed and accounted for?

Security

Are all security considerations properly specified?

Modeling and Design Views

When appropriate, are there multiple, consistent, models and/or views that represent the
design (i.e., static vs. dynamic)?
Where there are multiple models of the software (i.e., static and dynamic) are those models
consistent with each other?

© 2009 Regents of the University of Minnesota. All rights reserved. Page 4

JAD Session Facilitator’s guide

PROJECT PROFILE

Project Name

Project
Sponsor
Project Purpose/ This project is to…. Enter project purpose
Business Case

The expected project benefits include:

• Benefit – Enter project benefits

Likely Needed Proposed source of funds (departmental or unknown): Enter proposed source
Resources of funds

Project resources might include:

1. Internal Labor Resource (use $65/hour) $000,000
2. External Labor Resources (consulting) $000,000
3. Hardware $000,000
4. Software $000,000
5. Other $000,000
$000,000
Project Scope University Impact: Enter campus (Twin cities, all coordinate campuses, etc.)

Departmental Impact: Enter department

Functional Scope: Deliverable (New business process, new software,

purchase hardware, etc.)

Basic How will this project be done?

Approach Include the basic approach for this project.

Proposed Delivery Known or required dates:

Date Include any known or required project dates.

Possible Risks Consider things that can go wrong and impacts to not doing the project:
• Risk – Enter project risks

Additional Use this space for additional comments about this proposal (i.e., initial priority
Comments recommendations, known dependencies with other projects, etc.)

© 2009 Regents of the University of Minnesota. All rights reserved. Page 5

JAD Session Facilitator’s Guide

SYSTEM DIAGRAMS

AS IS Diagram:

TO BE Diagram:

© 2009 Regents of the University of Minnesota. All rights reserved. Page 6

JAD Session Facilitator’s guide

Draft Roadmap Outline:

© 2009 Regents of the University of Minnesota. All rights reserved. Page 7

JAD Session Facilitator’s guide

ISSUES LIST
Project Name: [Project Name] Project ID:
Project Manager: Last Updated:
Issue Priority Assigned Date Action Entered Entered Date
Category ID Issue Name Description of Issue (H/M/L) To Needed Taken Date By Status Closed

© 2009 Regents of the University of Minnesota. All rights reserved. Page 8

JAD Session Facilitator’s guide

COMMUNICATION MATRIX
Communications Goal:

Recipi Recipi Recipi Recipi Recipi Recipi Recipi Recipi Recipie

Document When How
ent ent ent ent ent ent ent ent nt
Project Definition Document
Project SOW
Project Overview Statement
Project Work Plan
Architecture
Work Breakdown Structure
Functional Design
Sizing Estimates
Budget
Communications Matrix
Project Schedule
Test/QA Plan
Change Requests
Status Reports
Implementation Plan
Training Plan
Lessons Learned

AP - For Approval
I - Informational
AR - As Required (indicates change)
UR - Upon Request

© 2009 Regents of the University of Minnesota. All rights reserved. Page 9

JAD Session Facilitator’s guide

TRAINING PLAN MATRIX

Training Goal and Purpose:      

Target
Training Distribution Location
Budget Audience & Message Content Timing Owner/s Status1
Components Method Requirements
Size

1
Status: P = Pending; C = Complete; O = Open

Training Positioning Strategy Summary:

© 2009 Regents of the University of Minnesota. All rights reserved. Page 10

JAD Session Facilitator’s Guide

SESSION NOTES

© 2009 Regents of the University of Minnesota. All rights reserved. Page 11