LeadershipChecklist™ CSS 350: Management Principles Last modified: 5/30/2014 Team members: Research ­ Rodelle Ladia Jr. User Interface ­ Bob Anderson Organization ­ Sota Ogo Design Architect ­ Samuel HyunGyu Kim Customer Interaction ­ Josh Brunner Discussion Facilitator ­ Jordan Walker

1 of 23

Version History Version Date of Changes Summary Editors

0.0 April 23, 2014 Initial document Rodelle Ladia Jr., Sota Ogo, Josh Brunner, Bob Anderson, Jordan Walker, Samuel HyunGyu Kim

0.1 April 24, 2014 ­ Refined documents as suggested by Professor Razmov. ­ Added features

Rodelle Ladia Jr., Sota Ogo, Josh Brunner, Bob Anderson, Jordan Walker, Samuel HyunGyu Kim

0.2 May 30, 2014 ­ Refined operational concept ­ Refined features ­ Refined lifecycle plan ­ Added detailed software architecture ­ Added more UIs ­ Added software design diagrams

Rodelle Ladia Jr., Sota Ogo, Josh Brunner, Bob Anderson, Jordan Walker, Samuel HyunGyu Kim

2 of 23

1.0 Table of Contents

1.0 Table of Contents 2.0 Operational Concepts and Market Analysis

2.1 Problem Description 2.3 Current Situation 2.3 Competition Analysis 2.4 System Objectives 2.5 Target Audience 2.6 Value Proposition

3.0 System Requirements 3.1 Features

3.1.1 Daily Goals 3.1.2 Leadership Checklist 3.1.3 Individual Reference Tracker 3.1.4 Communication Troubleshooter

3.2 Usage Scenarios 3.2.1 Scenario A: Understanding Leadership 3.2.2 Scenario B: Leading with Others 3.2.3 Scenario C: Assigning Roles

3.3 Non­Functional Requirements 3.3.1 Usability 3.3.2 Reliability/Security 3.3.3 Maintainability 3.3.4 List of Additional Non­Functional Requirements

3.4 Functional Requirements 4.0 Tools and Technologies

4.1 High­level Technical Description 4.2 High­level Software Architecture/Design

4.2.1 Application language 4.2.2 Server OS 4.2.3 Database System 4.2.4 Web Server and Web Language 4.2.5 Third party libraries 4.2.6 Architectural Style 4.2.7 Assumptions and trade­off on Software Design 4.2.8 Alternative designs

4.3 High­fi UI­mockups Figure 4.3.1 Tab Selecting Interface Figure 4.3.2 Mock up for Welcome Screen Figure 4.3.3 Individual Reference Tracker Figure 4.3.4 Communication Troubleshooter

3 of 23

4.4 High­level Design Diagrams 4.4.1 Domain Diagram 4.4.2 System architecture diagram

5.0 Lifecycle Plan 5.1 Stakeholders

5.1.1 Stakeholder Communication 5.1.1.1 Developers 5.1.1.2 Testers 5.1.1.3 Leaders in wild 5.1.1.4 Users 5.1.1.5 Investors

5.2 Objectives 5.3 Responsibilities

5.3.1 Team Description 5.4 Schedules/milestones 5.5 Development Methodology 5.6 Resources 5.7 Maintenance Plan

6.0 Feasibility Rationale 6.1 Project Risks

8.0 Bibliography 9.0 Appendix

9.1 Self Assessment I. Business­related aspects II. Project management­related III. Risks and assumptions IV. Feature­related V. Tools and technologies VI. Related work VII. Overall presentation

4 of 23

2.0 Operational Concepts and Market Analysis

2.1 Problem Description People realize that leadership is a necessary part of functioning in a team but often do not have the training or knowledge of how to be a successful leader. Leadership, like any skill, can be improved over time with practice.

2.3 Current Situation Currently available tools for improving leadership abilities are expensive, time­consuming, or overly generic. Leadership seminars and classes focus on general topics and do not allow users to practice improving their leadership over long periods of time. LeadershipChecklist™ is a unique solution that provides guided resources that help improve leadership.

2.3 Competition Analysis We identified competitors listed in Table 2. As looking at our competitors’ applications, LeadershipChecklist™ advances in providing suggestions according to each user’s situation. Table 2: List of competitors

Name Brief description

The Leadership Challenge Mobile Tool By Wiley Publishing

A mobile app for learning leadership skills by providing mini­lectures

Leadership Development By Smart Media Innovations Pty Ltd

A mobile app that provides news stories that are related to leadership skills to help users develop leadership skills

Personal Leadership App By Dale Carnegie & Associates, Inc.

A mobile app that provides on­demand leadership seminars.

KPMG Thought Leadership By KPMG International Cooperative

A mobile app that provides leadership issues/stories around the world

How2Lead 2.0 By The Ken Blanchard Companies

A mobile app that provides a news feed that focuses on leadership tips

2.4 System Objectives An application that allows users to improve their leadership ability without any formal training or need for leadership authority. The latest research in leadership is used to improve what information and how that information is presented to the user. To address time commitment issues, the application provides just that; a detailed analysis and articles are presented which can be expanded as necessary. The application allows users to improve their leadership over

5 of 23

time by providing daily goals and the ability to track their progress in developing leadership characteristics. LeadershipChecklist™ has sections and subsections which allow for detailed expandable examples and explanations. The application allows users to track their performance in specific leadership characteristics and provide goals. It provides resources such as checklists for new projects and recommends feedback.

2.5 Target Audience Our target audience is anyone looking to make a habit of improving their leadership without the significant time investment required by seminars and/or classes. Our main target age is between 20 to 40. Using our app, our users are able to track their progress and learn about their leadership skills while doing so. Those looking to improve their leadership abilities by becoming inspired to learn about the latest techniques will find our app extremely useful.

2.6 Value Proposition For anyone who looking to make a habit of improving their leadership without the significant time investment, LeadershipChecklist™ is an application that allows users to improve their leadership without any formal training or need for leadership authority. Unlike classes and seminars, this product inexpensive, customizable, and flexible around the user’s schedule.

6 of 23

3.0 System Requirements

3.1 Features This section contains the essential features for our system. It outlines what the features are as well as describes them more in depth. You can find usage scenarios of the features listed below in section 3.2 Usage Scenarios.

3.1.1 Daily Goals The Daily Goals feature is a box on the welcome screen of the app that presents goals that reflect leadership best practices. The daily goal feature will help the user to build upon their existing skills while teaching new skills. For example, to improve the user’s ability to communicate, a daily goal may be to ask team members for feedback on their communication style. Asking for feedback is an effective method for practicing communication (Stanonik) and helps to improve a user’s leadership skills.

3.1.2 Leadership Checklist Any new project started by a team can be difficult. With our system, the user is able to go through a checklist of tasks that reflect the best practices in leadership and is given information about why these tasks reflect best practices. For example, leaders must have a vision and be able to communicate that vision. The checklist explicitly asks the user if the project’s vision is clearly stated and provide sub­lists that help to clarify that vision. This feature interacts with the daily goals feature by providing a goal for the user to assess how well that vision is communicated by asking team members if they understand the vision and rating how well that person’s understanding matches with the user’s understanding of the vision. Inspiring and motivating team members is also a best practice related to leadership. When team members are able to have control over their own situation, it helps them to focus on the task and increases the amount of effort and persistence in achieving a unified goal (United States). To reflect this best practice, the application explicitly asks if team members have been assigned specific roles that provide them ownership over a piece of the project. The application can provide a possible list of responsibilities and descriptions and may interact with the individual reference tracker by suggesting roles that are tailored towards a team member’s personality type.

3.1.3 Individual Reference Tracker Every added team member will contain a notes section for the user to keep track of certain bits of information. The notes will include personality tests(such as MBTI, Myers Briggs, etc.), personal notes from the leader such as the member’s abilities and skills, preferences, trigger words, etc. This feature provides richer decision making when the leader wants to assign

7 of 23

roles through Leadership Checklist. For example, if the user want to do “Assign Roles” for the certain member, the reference will give information to the leader about what kind of roles fit better for the member.

3.1.4 Communication Troubleshooter Users identify problems when communicating with others and the application provides resources, checklists, or possible steps that can be taken to further identify and solve the problem. Communication is an important aspect of leadership. Therefore, this application can provide guidance for the user who would, otherwise, not have the time to look up the answer.

3.2 Usage Scenarios This section contains examples of usage scenarios. Specifically, they depict actual usage scenarios of a few of our essential features, as per mentioned in section 3.1 Essential Features.

3.2.1 Scenario A: Understanding Leadership Jake is a software developer for his CSS 497 team. He’s on a team of 6 other members and would like to focus his 497 project towards developing his leadership skills on a software development team. Using the Leadership Checklist feature of the app, he’s able to not only learn how his interactions with the team artifacts influence other’s decisions, but he’s able to see when and where he might be overstepping other people’s roles ­ bringing the entire team progress down. Using Leadership Checklist, Jake learns that overstepping member’s roles does not reflect the behavior of a true leader.

3.2.2 Scenario B: Leading with Others Janet is the project manager of a similar CSS 497 project as the one mentioned in section 3.2.1 Scenario A. She’s always been the driving force of every one of her team projects throughout her university courses. With the Leadership Checklist feature, she realizes that she’s not fostering an environment for her peers on the team to improve their skills. After logging her progress, the Daily Goals feature lets her know, through notifications, that she seems to be a strong participant in the team. Daily Goals suggests a goal to encourage other team members to participate in team activities. The suggestions provided let Janet know that doing all the work isn’t characteristics of a strong leader. Janet is so thankful to have learned more about team leadership while not having to go far out of her way to do so.

3.2.3 Scenario C: Assigning Roles Jayce is the project manager of a small game development team with two developers, two graphic designers, and one QA engineer. He has been taking notes about the personality and preference of each members. One of the designers, Kimberly is very good at creative work, but relatively weak at detailed painting. The other designer Wade is less creative, but very good at realistic detailed work. New characters are needed for the new game project they have just started a week ago. Jayce want to execute “Assign Jobs” to both of designer. There is a button that directly shows the notes that he had been taking for the members. Referring to

8 of 23

the note, Jayce assigned “Concept Art” job to Kimberly, and “Props and Clothes Design” to Wade.

3.3 Non­Functional Requirements

3.3.1 Usability The goal of the application is to provide quick references to information to help solve problems faced by those trying to improve their leadership abilities. The application should provide relevant information based not only on what the user is actively searching for, but for problems that can arise from common sources of conflict (for example, personality clashes or lack of communication). Without a usable interface, the user does not have access to the information they need and the value of the application drops dramatically.

3.3.2 Reliability/Security The application stores sensitive data about the user and the user’s views on project team members. This information is built up over time and would be very hard to replace if lost. The sensitive nature of the data limits the use of traditional, online data storage and backup schemes. The information should be transferred securely by encrypted way.

3.3.3 Maintainability Providing leadership feedback tailored to specific situations is an ongoing field of study. The application needs to be able to quickly integrate new information gained from research so that users are being given the most relevant information in improving their leadership abilities.

3.3.4 List of Additional Non­Functional Requirements ID Non­Functional Requirement Priority

NF1 The app must be build upon low­coupled modules High

NF2 The app must support unit testing for each module High

NF3 The app must enforce secure practices from its users High

NF4 The app use a secure connection (encrypted connection such as HTTPS) when the data is transferred between a mobile device and web server

High

NF5 The app must provide its service 24 hours a day High

NF6 The app must support popular mobile devices Medium

NF7 The app must have readable font sizes Medium

NF8 The app must provide maintainable contents management system for updating new contents by an administrator

Medium

3.4 Functional Requirements ID Functional Requirement Priority

9 of 23

F1 Users can create new projects High

F2 Users receive feedback on how to act as a leader for a project High

F3 Users can assign team members to projects High

F4 Users can assign roles to team members on a project High

F5 Users can enter a textual version of the vision for the project High

F6 Users can plan meetings High

F7 Users will be able to set up a user name associated with their email High

F8 Users will have a profile page associated with their user name High

F9 A user’s private notes are encrypted and require the user password to decrypt High

F10 The user’s data is periodically saved to the phone’s memory High

F11 Users will be able to give the product owner feedbacks about the app High

F12 Users can add and reference notes of individuals on a team Medium

F13 Users receive leadership advice based on an team members’ personality style Medium

F14 Users can access a mailbox function to send and reply to team members Medium

F15 App contains a database that contains daily tips Medium

F16 Daily tips provide are tailored to the user’s project Medium

F17 The app will provide the ability for users with seeing disabilities to enlarge font size

Medium

F18 Users are sent project reminders for their individual projects Low

F19 Users can view a visualization of their projects and progress Low

10 of 23

4.0 Tools and Technologies

4.1 High­level Technical Description The main value of the program is in the information that is presented to the user. Mobile application development (using Java) allows us to use a familiar framework for developing a user interface that can access the information provided by research into leadership training.

4.2 High­level Software Architecture/Design The following sub­sections aim to identify the software architecture that should be implemented upon approval of this project’s proposal.

4.2.1 Application language This application will be written in different languages depending on the environment in which the application will need to operate. For the initial implementation (which will be on Android devices), the application will be written in Java. For future implementations (currently unplanned), on IOS the application will be written in Objective­C, and on Windows Phone OS the application will be written in C#.

4.2.2 Server OS This application will pull all of it’s user information and leadership information from a central server. This server will use Windows Server 2012 as its operating system.

4.2.3 Database System The information utilized by this application will be stored in a Microsoft SQL 2012 database which will be maintained with an administrative web front­end.

4.2.4 Web Server and Web Language In order to maintain the database and add leadership information, there will be an administrative web front­end hosted by Microsoft IIS and programed in ASP.NET 4.5.

4.2.5 Third party libraries Due to the simplicity of this app it is feasible for us to complete this project without the use of third party libraries, so the majority of the work will be done from scratch in order to maintain control of our codebase.

4.2.6 Architectural Style Because of the nature of the web­based application, the software will be build based on two main architectural styles, Model­View­Controller (MVC) and Representational state transfer (REST), for the server­side application.

4.2.7 Assumptions and trade­off on Software Design Table 4­1 shows assumptions and trade­offs for specific technologies chose.

11 of 23

Table 4­1: Assumptions and trade­offs

Assumptions Trade­offs

Mobile languages (C#, Objective­C,Java)

Although using a common language for all the mobile platforms (by using a build tool such as PhoneGap) is cheaper in terms of the labor costs, it is much better to use mobile specific languages to increase the app performance.

Windows Server 2012 Many popular web services are using linux­based OS for a server so there might be fewer information about the web development; however, Windows server 2012 is more reliable than others according to our experiences.

4.2.8 Alternative designs There are many alternative designs we could have gone with for this system, but overall we believe the path we have chosen is the best. The main difference between the design we chose to go with and the bulk of the other possible designs is the use of a Windows Server backend instead of a Linux backend. Going with a Linux backend obviously would have changed a lot about our system simply because its toolchain is almost entirely detached from Windows. The main reason we decided to figuratively “bite the bullet” and go with a Windows based system is Windows offers a lot of support for their systems and Linux being a mainly open sourced entity does not offer support. The support that Microsoft offers for Windows could prove to be invaluable in a time of need for our software.

12 of 23

4.3 High­fi UI­mockups

Figure 4.3.1 Tab Selecting Interface Figure 4.3.1 shows how user can jump among the main features. On any screen, if the user swipe the screen from left to right, it will show the current tab and tabs that user can jump.

Figure 4.3.2 Mock up for Welcome Screen Figure 4.3.2 shows the tips of the day and the daily checklist for leadership. as soon as the user clicks tips or a certain role, the details will appear on the screen.

13 of 23

Figure 4.3.3 Individual Reference Tracker Figure 4.3.3 belongs to the main feature Individual Reference Tracker. The user can add individual references for coworkers. This references will be used for decision making with the person.

Figure 4.3.4 Communication Troubleshooter Figure 4.3.4 shows Communication Troubleshooter which will provide the recommended steps for the user who meets communication problem. The user can choose the type of the communication problem, and according to the problem, the application will show the suggestions that can help solving the communication problem.

14 of 23

4.4 High­level Design Diagrams This section identifies the modules and components of our software on a high level. Many of the parts required to make this system are listed here along with basic information about how these parts of the system interact with each other. Furthermore, this section of the document considers other possible designs for this system and identifies why the chosen system might be better

4.4.1 Domain Diagram Figure 4­1 depicts the high level components of the system and roughly how they interact with each other in the form of a domain diagram.

Figure 4­2: Domain Diagram

15 of 23

4.4.2 System architecture diagram Figure 4­2 shows the high level components of the system. Between Mobile devices and the web server, user information and dynamic contents will be transferred.

Figure 4­2: System architecture diagram

16 of 23

5.0 Lifecycle Plan

5.1 Stakeholders This section contents a list of stakeholders.

Developers Testers (and QA) Leaders in wild Users Investors

5.1.1 Stakeholder Communication As with any project’s success, communication with stakeholders throughout the process is very crucial. Since we’ve suggested that the SCRUM methodology is used throughout implementation, communication with the stakeholders will occur at minimum on a monthly basis.

5.1.1.1 Developers For the developers, communication will be on a daily basis. This is because development and communication in an environment where open dialogue is encouraged. It is proven that this kind of environment supports high levels of productivity.

5.1.1.2 Testers For the testers, communication will be on a weekly basis. Since it is up to the testers to ensure that the work that the developers are doing is working in a manner that is appropriate to uphold the company’s reputation. Therefore, it is vital that the testers are able to communicate with the developers at least one day a week.

5.1.1.3 Leaders in wild Since our application focuses on providing useful leadership tips and recommendations, it’s important to maintain a reliable level of leadership expertise being recommended to our app. However, since leadership styles is not something that changes on a daily basis, communication with actual leaders is only required on a monthly basis.

5.1.1.4 Users Users can communicate with the product owner via our app by a feedback function. This happens when users notice any issues or improvements of the app.

5.1.1.5 Investors As we plan on using the SCRUM methodology, we encourage the investors to attend meetings that will be held at the beginning of Sprint and at the end of Sprint. Opinions are welcomed during the meetings.

17 of 23

5.2 Objectives Ensure that high quality systems are delivered, provide strong management controls, and maximize the productivity of the systems. We aim to be able to deliver a product that helps its user to learn more about their leadership skills as well as motivate them to explore new attributes of strong leaders.

5.3 Responsibilities This section explains what type of professionals we need to complete this project.

5.3.1 Team Description Table 5­1 shows the team organization and job descriptions for this project. Table 5­1: Team organization and Job descriptions

Title Role Description of duties

Qualification Number of Employees

Scrum Master

Organizing and leading the group

Keep the Scrum going in the right direction and on time.

2+ years recent web/mobile development project experience and 1+ years project management experience

1

Lead Developer

Architecture and Design Choices

Lead the development team as well as developing

5+ years recent web/mobile development project experience

1

Junior Developer

Software Development

develop/implement the functions

1+ years recent web/mobile development project experience

2

Lead Designer

Customer Interaction

Lead the design team as well as designing

5+ years recent web/mobile development project experience

1

Junior Designer

Usability Design

Design the interface of the system

2+ years recent web/mobile development project experience

1

Quality Assurance Intern

Clarifying and Summarizing

Test the service 1+ years recent web/mobile development project experience

1

Total: 7

18 of 23

5.4 Schedules/milestones Table 5­2 shows milestones and tentative schedule for the project's implementation over the course of one year worth of development. Table 5­2: Schedules and milestones Milestones Description Milestone Criteria Planned Date M0 Start Project Budget Release Month 1 Requirements

Validation Focus group studies used to validate and refine final feature requirements.

Month 1­2

Complete high­level design and research

Pile requirements up in Product backlog and Sprint backlog.

Month 2­3

Customer Approval and design changes

Meet with the customer/s and get their written approval of the design

Month 3

M1 Start Construction Iterations

Sprint starts Month 3

M2 Launch version alpha Testable application is released to internal testers to receive feedback

Month 6

M3 Launch version beta Fully functional application is released to the public (some bugs may still exist)

Month 8

M4 Launch version 1.0 Fully functional application “bug­free” is released to the public

Month 10

M5 Maintain and evolve the software

New research is consistently added to the database, and new features are added

Month 11 ­ N/A

M6 Retirement “Get off my lawn!” N/A

5.5 Development Methodology During implementation, we suggest that the SCRUM management process is used.

5.6 Resources Six months is needed to validate user requirements and develop an initial prototype, and an additional six months is required to fully assemble the knowledge database and polish the user interface. The actual program isn’t complex, and the user interaction with the program is highly dependent on the presentation of available research.

5.7 Maintenance Plan As a maintenance plan for this system, we propose that new features are added to the backlog during the monthly meetings that the stakeholders shall have. Any issues or bugs that arise, shall be dealt with according to their priority in the backlog.

19 of 23

6.0 Feasibility Rationale

6.1 Project Risks This section is a depiction of the risks that our team has identified. Table 6­1 shows a table of risks and their mitigation procedures. In addition, each risk has characteristic associated with it. These characteristics are Probability, Impact, and Exposure. Table 6­1: Project Risk Descriptions

Probability Description Mitigation Impact Exposure

Probable If the app crashes, there’s a risk of the user’s input not being saved properly. This might result in data loss.

Create an autosave feature in the app to handle interruptions

Serious Medium

Probable If Daily Goals suggests things to the user that does not improve their perception of leadership.

All Daily Goals are to reflect the latest in leadership research.

Serious High

Probable If we as a team can’t complete our project proposal by the deadline, the project will never see the light of day.

Careful planning and organization by the team will result in completion.

Critical Intolerable

20 of 23

8.0 Bibliography

Angier, Michael. "Top Ten Ways to Inspire Others to Be Their Best." "Top Ten Ways to Inspire Others to Be Their Best" by Michael Angier. Success Networks International, n.d. Web. 29 Apr. 2014.

Garcia, Helio. "How to Use Communication to Build Trust and Inspire Loyalty, as Well as Lead

Effectively." How to Use Communication to Build Trust and Inspire Loyalty, as Well as Lead Effectively. American Management Association, 17 Sept. 2012. Web. 29 Apr. 2014.

Martin Luther King Jr. "I Have a Dream." Martin Luther King I Have a Dream Speech ­

American Rhetoric. 28 Aug. 1963. Web. 28 Apr. 2014. "Organizational Assessment: How Does a Company Conduct a Training­needs Analysis?"

SHRM. Society for Human Resource Management, 27 Nov. 2012. Web. 01 May 2014. Rafferty, Alannah E., and Mark A. Griffin. "Dimensions of Transformational Leadership:

Conceptual and Empirical Extensions." The Leadership Quarterly 15.3 (2004): 329­354. Web.

S­Cool. "Management, Leadership, Motivation and Communication." GCSE Revision and A

Level Revision. S­cool, 16 Sept. 2010. Web. 29 Apr. 2014. Shambaugh, Rebecca. "Five Tips on How to Inspire Your Employees in Challenging Times."

Hiring, Recruiting and Staffing Solutions. Monster.com, n.d. Web. 29 Apr. 2014. Silverstein, Barry. “Best Practices: Motivating Employees: Bringing Out the Best in Your

People”. New York:HarperCollins Publishers, 2007. Stanonik, Rebecca. "Better Business Center." Better Business Center. Torkusa.com, 10 Oct.

2013. Web. 29 Apr. 2014. United States. “Army Leadership: Field manual 6­22.” Washington, DC. Headquarters,

Department of the Army. 12 Oct. 2006 Web. 1 May 2014

21 of 23

9.0 Appendix

9.1 Self Assessment

I. Business­related aspects

name: brand whole product market analysis Market analysis is the next

crucial point in this project by doing market research. By doing so we should be able to create concrete marketing strategy to be financially successful.

communication plan with stakeholders

II. Project management­related

time frame (full life­cycle) resource description (people, etc.)

milestones support/maintenance plans after shipping

progress been made since the last deliverable: is it sufficient?

III. Risks and assumptions how critical each one is corresponding mitigation plans

22 of 23

IV. Feature­related ­­ most critical functional and non­functional requirements ­­­ which ones do stakeholders need the most?

UI In the current UIs, They don’t cover small functions like user feedback, so the next step will be identifying all the required UIs for this project.

V. Tools and technologies includes a description of technologies to be used

overall architecture/design, use of frameworks

feasibility taken into consideration (if starting from scratch, if using 3rd party libraries, etc.)

VI. Related work What others have done / found before?

Why (and where) yours is better?

VII. Overall presentation

professionalism, style, TOC, CRAP principles

23 of 23