Audit Report

APA 7th  

Managing Troubled Projects

 I’m not sure if other documents are needed. We can discuss again after you review the documents I uploaded.

PJM 6140
Midterm and Final Exam

Supporting Info – Notes from Instructor

To minimize confusion, when working on the project schedule, assume it
is November 2, 2015 and you have just been hired as the new project manager on
the Health Systems case.

For the midterm:

Once you have read all the files, I am sure you’d have discovered a number of problems
with the case. My recommendation is to take some notes down as you go through the
files a second time. Ask yourself: What seems out of place, what is not accurate, what is
out of order?

Once you are done with the notes, you can group them in order of the different
requirements for the assignment. You can expand on each of your notes by
synthesizing some of references from the weekly lectures and assigned material. This
should help you put together a good audit report that addresses the necessary points.

For the final:

For assistance, recall each lesson from weeks 4-6. What did we cover in week 4? Any
of the factors we discussed that apply to this case? What did we talk about in terms of
re-scoping a troubled project? What about the re-estimation? What about the baseline?
As you recall each of the lectures and the assigned reading material that you read, you
will find that many of these apply to this case.

Next, keep in mind that as with many troubled projects, available information is poor and
somewhat unclear. The final exam case is designed purposefully with such unclear
information. It is up to you, the project manager, to make reasonable assumptions, and
to address the requirements of the assignment based on these stated assumptions. As
a result, I expect that you will build from your specific recommendations in the midterm,
and layout a course of action, based on these recommendations.

Do you need to determine the correct date? Yes, there is a discrepancy in the
information as to the final date, so you will need to make a determination which is
correct and layout a plan that will meet the recommended date. The plan should be
logical and based on improvements to the project schedule.

For this work, you do not need to create new requirements. Though this would need to
be done, this is not a business analysis course, or a system design course. This is a
course on recovering troubled projects and your role is that of the recovering project
manager. You can reuse the existing requirements, but indicate in your paper if some
requirements are missing and how you plan to address such gap.

Same with the requirements traceability matrix, but you will need to indicate the issues
that you uncovered with the requirements and how you plan to address these based on
the lessons we covered in the course.

Should the project be terminated? No. I expect that you will make a recommendation for
recovery and explain how you will recover the project.

Hope this information helps. If you still have additional questions, please post them in
the Q/A forum so that all of your classmates can benefit from any further clarifications.

Project Audit Report

Abstract: The Project was to deliver Customer
functionality within four to seven months of
inception (October 2000). The project was
unable to meet that deadline and an audit was
requested. This document presents the
findings of that audit.

Author: Todd C. Williams
Date: 18-Nov-2000
Revision: 1.3.2
Pages: 8
Status: Released

Table of Contents
Table of Tables ii
1 General 1
1.1 Purpose 1
1.2 Scope 1
2 Audit Results 1
2.1 Background 1
2.2 Summary of Findings 3
2.2.1 Lack of Customer 3
2.2.1.1 Customer Representation 3
2.2.1.2 Data Entry Bias 3
2.2.1.3 Drift From A Customer To Data Entry Focus 3
2.2.2 Decisions 3
2.2.2.1 Definition Team Leadership 4
2.2.2.2 Lack of Customer Meant No Decision Maker 4
2.2.2.3 Team Members Going Around Management 4
2.2.3 Lack of Interest 4
2.2.3.1 Business Lack of Involvement 4
2.2.3.2 Dead product 4
2.2.3.3 PMO/Program Focused On Other Issues. 5
2.2.3.4 Hands-off Approach By The Project Manager 5
3 Detail 5
3.1 Lack of Customer 5
3.2 Decisions 7
3.3 Dysfunctional Project Management Structure 7
3.3.1 Stakeholder Involvement 7
3.3.1.1 Data Entry 7
3.3.1.2 Sales/Customer 8
3.3.2 Project Team Structure 8
3.3.3 Project Oversight 8
4 Requirements Prior to Proceeding 9
4.1 Failed Project 9
4.2 Reset Project and Role Definition Project Personnel 9
4.3 Accelerated Schedule Will Be High Risk 9
4.4 Define Decision Authority 10
5 Appendices 10
5.1 Appendix A – Individuals interviewed 10

Table of Tables
Table 1 – Objectives Removed from the Audit 3

Reference Documents
Document Name Revision Date
Project Vision V1.1 July 10, 2000

Steering Team
Presentation deck

N/A March 22, 2000

Steering Team
Presentation deck

N/A March 31, 2000

1 General
1.1 Purpose
The purpose of the document is to present the findings of the project audit.
1.2 Scope
This document identifies the major problems with Project Definition, Project
Management, stakeholder roles in relation to the project and items to fix prior to
continuing the project. It does not address other, potentially significant, risk in running
the project nor does it make a recommendation on whether the project should continue
or whether it will be successful even with these problems corrected.
2 Audit Results
2.1 Background
Corporate PMO requested an audit of the project in order to determine the source of
significant schedule slides. At its inception, this project was one of a few select
projects identified as being simple enough to proceed through definition, development
and delivery in calendar year 2000. These projects were identified in late March 2000
and needed to be implemented prior to Q3 2000 requiring a six-month cycle for the
project.
In August, the Project Manager informed the PMO and the business that the
requirements phase would complete in April 2001 and they were unable to provide an
estimate on the delivery date.
The Recovery Guidelines for the audit were to:

1. Determine the root cause for the projected slide in the requirement phase.
2. Determine if the people associated with project had the correct skill set.
3. Determine if the team was executing the corporate methodology correctly.
4. Determine if the proposed go-forward plan was viable.
5. Assess the proposed re-scope options to determine if they were sensible.
6. Define success criteria for the project.

In order to expedite the audit and move the project forward, the audit was restricted
to:

1. Determine the root cause for the projected slide in the requirements phase.
2. Determine if the people associated with project had the correct skill set.
3. Determine if the proposed go-forward plan was viable.
4. Define requirements to proceed with the project.

Table 1 addresses the removed items.
Item Method of addressing
Determine if the corporate
methodology was being executed
correctly.

The corporate methodology was not being
followed. The team was redirected to follow
a process to fit inside that generic
framework.

Assess the proposed re-scope options
to determine if they are sensible.

The team was re-directed prior to
completion of the audit to an option outside
the PCR. A new PCR will be submitted.

Define success criteria for the project. The business must address this rather than
the project team. Hence, it was changed to
“Define requirements that must be met
prior to proceeding with the project.”

Table 1 – Objectives Removed from the Audit

2.2 Summary of Findings
2.2.1 Lack of Customer
2.2.1.1 Customer Representation
The Project Vision document clearly defines the Company’s customer as the customer
for this project. Data Entry is noted as a secondary benefactor from functionality

provided to the Company’s customer. The business advisory team is composed of Data
Entry Subject Matter Experts (SME) and Business Analysts (BA). This changes the
focus of the project at the lower level (BA-level) but the project management level
remains focused on the Company’s customer. Since the Data Entry centric Business
Analysts are in conflict with the project management team, they chose to solicit
support from executives in the Data Entry organization. This is allowed to proceed by
the Data Entry executive. Any form of scope control is useless due to this lack of
command and control.
2.2.1.2 Data Entry Bias
The definition team members are mostly from the Data Entry group and are led by two
people, a business analyst from Data Entry (the lead) and another from Sales (a part-
time analyst). It is unapparent who has the actual authority, but the lead from Data
entry does not believe he has the authority.
2.2.1.3 Drift From A Customer To Data Entry Focus
Using the Project Vision document (the only known written source of project
objectives), the Company’s customer is the customer of the project. This focus has
shifted over the life of the project. There are a number of contributing factors to
exacerbate this drift in scope. Two are worth noting:

1. Business Analysts (BA) and Subject Matter Experts (SMEs) are all from Data
Entry and are unaware of the immediate needs of the Company’s customer. An
advisory team composed of the Company’s customer is missing and needs to be
formed.

2. Since this project is tactical and there will be no follow-on maintenance, the
attitude of many team members is “If the project is unable to built features into
the system on this release, they will never be provided.” This attitude created
an atmosphere of asking for everything.

The result of this is that the project started with a vision that “What is good for the
Company’s customer is good for Data Entry” and changed to “What is good for Data
Entry is good for Customer.” Both statements are true, but the latter increases scope.
2.2.2 Decisions
The definition team, often referred to as the Business Analysts (BA), is actually a team
that consists primarily of Subject Matter Experts (SMEs). The primary difference
between these to qualifications is business domain knowledge. An SME has narrower
domain knowledge. The lack of experience of the definition team creates a void of
experience in negotiating scope and limiting other team member’s requests. No one
can prioritize or break a tie within the definition team. Essentially, the people are
empowered but have no leadership and, therefore, they cannot make a scope decision.
2.2.2.1 Definition Team Leadership
The definition team is missing leadership and the Project Manager appears uninvolved
and powerless to change that. Even when people are removed from the project, they
continued to exert pressure on the project through direct contact with the team or
executives to apply external pressure on the project.
2.2.2.2 Lack of Customer Meant No Decision Maker
During audit interviews, one question was always asked consistently—Who is the
customer? There are four answers to this question—the Company’s customer, Data
Entry, both and unsure. There is no pattern to this answer. Senior management is
inconsistent in their response as well as the project team. Without having a defined
customer, there is no litmus test for what is in or out of scope.
2.2.2.3 Team Members Going Around Management
At least one manager (that is admittedly not the project sponsor) is blind copied on
project information and indicates she receives regular updates from the definition team
(bypassing the Project Manager) on the direction of the project. This is framed as
being given to the manager “to protect her best interest.” This manager passively

provides input that directs the definition team without knowledge of the Project
Manager.
2.2.3 Lack of Interest
2.2.3.1 Business Lack of Involvement
During the audit process, the Vice Presidents in charge of Sales and Data Entry were
interviewed. It is apparent that there is significant lack of involvement of the
managers. Neither considered themselves providing the function as the sponsor of the
project. Sales (the key representative of the Company’s customer) was uninvolved
with the project until late August.
None of the Data Entry executives feel they are the sponsor, but are very involved in
an indirect manner.
2.2.3.2 Dead product
Many team members are under the impression that this product is being built as a
stopgap; the term “dead product” is often used. The result is two different negative
attributes for the project.

1. The definition team (secondary users of the product) has the attitude that if
they are unable to build in everything they want in this release, they will never
get built.

2. Some people lost interest since it is a throwaway system—building something
that will be quickly thrown away decreases the enthusiasm of the team.

2.2.3.3 PMO/Program Focused On Other Issues
The number of projects handled by the PMO/Program created a distraction and it
appears that the project and project manager are unmonitored and the project is
allowed to follow its own “free path.” The program focus appears to be on the strategic
projects.
2.2.3.4 Hands-off Approach by The Project Manager
The Project Manager runs the project with a very hands-off approach. He relies solely
on the leads (referred to as the core team) to provide his contact with the teams within
the project. The team members interpret this as lack of interest.
3 Detail
Following are a series of observations that were used in compiling the summary. They
are listed to provide a background for the report.
The audit discovered numerous problems. Three of these items are considered major
contributors to the failure. Short-term tactical nature of the project has little effect on
the project. The issues found would be damaging to any project. The problems are
amplified by the four to seven month delivery target.
3.1 Lack of Customer
Critical to delivering any project is clear identification of the customer and of the
definition of the project objective.
The group of people that will use the system is the customer. If there are multiple
groups with different objectives, priorities must be set to identify the sub-group that
should have the focus. The more diverse the customer base, the wider the scope and
the higher the risk for the project. A conflict, therefore, exists between meeting the
needs of a wider customer base and completing the project in a short timeframe.
During the audit, it was clear that there was significant confusion on which group was
the project’s customer. Depending on who was asked, the customer was defined as
Sales, Data Entry, the company’s customer or a combination. This lack of concise
definition broadened the scope of the project and obscured the prioritization. Although
the general functional requirements of the Data Entry Group and the company’s
customer are similar, the Data Entry group requires handling of a number of special
cases. Adding Data Entry to the set of customers:

1. Increased the scope of the project;
2. De-focused the objective of the project;

3. Obfuscated the prioritization of the requirements;
4. Decreased the options for accelerating the project.

3.2 Decisions
Decision processes in the project are broken. This appears to come from a wide
variety of issues and indicates multiple problems in the organizations. The following
were the primary problems:

1. Ultimately, the owner of the system (the group paying for the system) is the
group to make decisions on the scope. Neither the customer nor owner is
defined. Without either of these, the ability to get a decision on what to build is
impossible.

2. The project structure is a team-of-teams. This is supposed to enable each team
(definition, development and QA) to make their own decisions; but since there
is a lack of definition on the objectives, there is insufficient information for this
to work. Nearly all decisions are escalated.

3. Scoping decisions are left open since the vision of the project (based on the
Project Vision document) is to meet the needs of customers, but the focus of
the definition team was Data Entry. This creates a conflict in the objective of
the project.

4. The definition team members are titled Business Analysts (BA) but are actually
Subject Matter Experts (SME). They lack an understanding of the general
business scope inhibiting their ability to make decisions on what is most
important to the Customer.

3.3 Dysfunctional Project Management Structure
For the purposes of this document, project management structure is considered:

1. The Project Sponsor;
2. Project management oversight;
3. The project team structure.

All levels of the project management structure had considerable problems that
contributed to the failure of the project.
3.3.1 Stakeholder Involvement
Although there is a team of people from the business unit involved in the project, there
is no direct Project Sponsor involvement. Stakeholder representation from the Sales
group was absent until August, and the Data Entry stakeholders feels they had no
direct involvement.
3.3.1.1 Data Entry
The Data Entry group has plenty of representation since the definition team consists
primarily of Data Entry personnel, but is lacking sanctioned input from the Data Entry
stakeholder. The interactions with this stakeholder are most politely termed as
inappropriate. Information purposely flows from the definition team to the Data Entry
executive around the project manager—an action that might be better termed as
subversive. This is done, as termed by one of the team members, because “the project
manager did is ignorant of the business.” The Data Entry stakeholder encouraged the
covert flow of information.
3.3.1.2 Sales/Customer
The company’s customer is represented by a single person from the Sales group but
she has insufficient input from the Sales group as a whole and no input directly from
the company’s customer. The Sales stakeholder started participating in August 2000.
3.3.2 Project Team Structure
The structure of the project is a team-of-teams. Although this structure is acceptable,
it requires that each team lead is accustomed to the role and focused on being a
manager. None of the team leaders have the experience of working in such a
structure. At least one lead is notably struggling with the workload; another is lacking
respect (hence no authority) since the team does feel the lead is missing business

experience. This structure slows the progress and creates animosity in the team
resulting in Business Analysts going around the project management structure and
getting decisions overridden. The business unit neither stops this process nor brings it
to the attention of the Project Manager.
The Project Manager empowers and trusts the individual team leads to guide their
teams properly, but has failed to verify the team-of-teams concept is working. He
should have verified the progress and attitude of the team. He is hands-off and out of
touch with the team.
The Project Manager is ultimately responsible for the function of the project team and
should have highlighted the problems to management. The Project Manager fails as
the safeguard to alert management.
3.3.3 Project Oversight
It is the Project Manager’s responsibility to identify and escalate the problems on the
project. It is the responsibility of the PMO and Program to provide project oversight to
ensure the project is progressing. As with the Project Manager, the Program
Management Organization has no involvement with the project and was unable to see
the failure coming. To use an airline analogy, the pilot of any airplane is responsible
for completing a walk-around of the plane. This is to identify any obvious issues that
the maintenance teams might have overlooked. In this process, the pilot sees the
state of the aircraft and the state of the team maintaining the aircraft. This concept is
used by many managers to get a feel for the progress of their teams and interactions
between them. Speaking only for this project, this process was entirely missing from
the project management structure. Although the genesis of this behavior is not fully
understood, it is likely rooted in the short-term, tactical nature of the project and their
focus on more strategic issues.
4 Requirements Prior to Proceeding
In order to continue with the project, a variety of issues must be resolved. Define the
project customer. The customer must a homogenous group with similar simple needs.
Without this, complexity and scope will increase. This group ultimately confirms the
value of features to be implemented.
Since this is currently lacking from the project, an assumption must be made prior to
completing these recommendations. Therefore, the following requirements are based
on this assumed objective:
The Project is a short-term project that provides value to the Company’s customer in
maintaining their data using a web-based payment, client maintenance and billing tool.
The project will determine the functionality to be delivered based on achieving
beneficial functionality in the shortest time possible. The first delivery should be within
six-months of project restart. Follow-on functionality will be delivered in subsequent
releases. The measurable goal of the project will be to provide functionality to the
Customer that will increase the use of the web-based system.
4.1 Failed Project
Because the project has been misguided and there is a significant negative view
crippling the project, it will have difficulty proceeding. Lack of interest will be amplified
since it is tagged as a failed project. Public condemnation of the project must stop.
4.2 Reset Project and Role Definition Project Personnel
The project will need to be reset; the lack of direction, customer and sponsor must be
resolved. This must be achieved at the business executive level. A single sponsor
must be identified; all requirements, guidance and decision making must be the
responsibility of that person. The Project Manager must approve scope as being
tactical in nature, focused on the Company’s customer and achievable in a short
timeframe. Any actions to circumvent the sponsor or the Project Manager must be
stopped.
Currently, the project team has failed to align with the business. One of the first tasks

must be alignment and approval of objectives.
4.3 Accelerated Schedule Will Be High Risk
The original schedule for delivering functionality in four to seven months was a gross
underestimation of the time required to deliver functionality. This appears to continue
to be the case. There are at least nine calendar months of work required prior to
deployment, significantly over the seven-month goal stated six months ago.
Attempting to accelerate the schedule further will increase the risk, which is already
high.
4.4 Define Decision Authority
Scope must be contained. Based on the assumptions made above, decisions to limit
the number of business rule validations or editable fields must be made to limit the
work and focus the team on the delivery. These decisions will need to focus on the
most important functions to the Customer to increase their usage of the system.
Functions beneficial to Data Entry may be de-prioritized in order to maintain schedule.
The trade-off will be the responsibility of the Project Manager and the sponsor.
5 Appendices
5.1 Appendix A – Individuals interviewed
Name Role
QA Team Lead
Director IT Project Office
Analyst team member
Program Manager
VP Sales
Analyst team member
Definition Team Lead
QA Team
Past Analyst team member
Analyst team
Program Executive
Enterprise Arch Lead-Solutions
Project Manager
Sr. VP
VP Information Technology
Development Team Lead
VP Data Entry

Work Breakdown Structure Sheet Example
The following is a completed Work Breakdown Structure page from a proposal. For
more information on its use, refer to Error! Reference source not found.. A
template for this may be found on the Back From Red Website (http://Error!
Reference source not found.).

1. WBS Number: 3.3 Functional Specifications and ATS
Description of Task:
Develop Functional Specifications and Acceptance Test Scripts for the systems to be
developed and/or purchased to fulfill Customer requirements. The preliminary list
of systems be specified are:
Automatic Data Collection
Metrology
Process
Test
Online Statistical Process Control
Material Control System Interface

1. WBS Number: 3.3 Functional Specifications and ATS
Recipe Management System
Advanced Scheduling/Planning System
ERP Interface
Tester Server Systems
MES Expanded Services
Costing System
Serial Number Tracking, Components to Higher Level Assembly
Internet Interface
Document System
Customer Order Tracking
Document Management System
Palm Pilot Interface
Shop Floor Document Hypertext System
Deliverables:
Functional Specification and Acceptance Test Script for each major item listed
above.
Dependencies:
Requirements Definition Complete.
Assumptions:
Systems for the new fabrication unit are designed and understood.
Responsible Customer parties have been assigned and are accessible for reviews of
documents.
Exit Criteria:
Approved Functional Specifications and Acceptance Test Script.
Task Owner:
Supplier

Sample Change Request Form
The following is an example of filled out a change request form. For more
information on its use, refer to Error! Reference source not found.. A template
for this form and a complete Change Management process may be found on the Back
From Red website (http:// Error! Reference source not found.).
Change Management Request (CMR) Form
CR# 44
PROJECT: ___SemiMan MES Implementation_________
INITIATION
CR #: 44 Initiated by: Todd Williams Date: 21-Aug-1997
Type:

Design
Application
Database
Documentation
Other

Client Req:

Yes
No

Priority:
High
Medium
Low

Category:
Error
Enhncmnt
Other:

Scope
Change:

Yes
No

Short Description of Issue:(10 words or less):
Additional definition of Alarm Manager input required for proper correlation of
information
Detailed Description of Issue (Include attachment if necessary):

1. Subsystems are missing a method of generating a predictable Alarm Manager
action result. For instance if the Subsystem needs an ACK message, it requires
a predefined Alarm_ID to do this.

2. Additional definition of sub-system message mapping to Alarm Table Alarm ID
is required to allow translation of the subsystem alarm to an Alarm_ID.

3. Replaceable parameters in messages need to be predictable and defined. A
better method is required to provide basic system functionality.

4. Message logging should be based on the more than the Alarm table
configuration. Message content should be added to the log to ensure that all
relavent data is retained.

INVESTIGATION/RECOMMENDATION
Assigned
to:

Claude Billings Date
assigne
d:

8/19/97 Projected
completion:

8/19/97

Solution Architect
Approval:

Signature:

Findings of Investigation (Include attachment if necessary):
1. Alarm ranges are to be further defined in the architecture document and a

specified range will be reserved for subsystem use.
2. Subsystems must have the capability of mapping the subsystem message to

alarms in the Alarm Manager.
3. Definition of three primary positional parameter values (InputParameter,

OriginalAlarmID, OriginalAlarmText) should be standardized and should have a
method that allows for identifying the parameters.

4. All parameters and the associated names should be written to the MESSAGE log
files as shown below. Refer to CR #43.

a. Parameter List: {“EquipmentID”, “OriginalAlarmID”,
“OriginalAlarmText”,…,“NAMEn”}.

b. Parameter Name List: {“Eqpt1”, “10.25”, “Actuator
failure”,…,“VALUEn”}.

IMPACT:
Estimated time to
complete:

70 hours Date to be
completed:

9/30/97

Cost: $5,800 Schedule Impact: None
Documents Affected:
Alarm Manager Design Specification
EI-Host Message Set
SemiMan Systems Architecture
Comments:
Coding will need to be changed in the GUI/RetManager, GUI/EIManager, GUI/MES,
GUI/PODS, GUI/Batch, GUI/Lot Reservation, GUI/Carrier management, EI, EIM/RMS
and Sorter. The Alarm manager must be modified to reflect the added data. Each
sub-system responsible party must compile a list of errors generated and determine
the criticality of these messages as relates to the Alarm Manager.
This list will need to be reviewed by SemiMan for finalization.
The final list will be loaded into a sub-system table to be used for the mapping.
SemiMan must maintain the Alarms Table data

PJM 6140– Managing Troubled Projects – Week 3: Individual Assignment – Midterm

Overview and Rationale

In order to demonstrate proficiency with the content in this course we will complete a number of different assignments to validate
your learning – and allow you to implement relevant practices a real-world setting.

PJM 6140 Learning Outcomes

This assignment aligns with the following learning outcomes

• Demonstrate an ability to review projects and identify when a project is failing or troubled
• Define and select strategies for avoiding failed or troubled projects
• Determine the health of a project through an audit or assessment
• Develop a troubled project recovery plan
• Plan and execute a failed project shutdown

Essential Components
Now that you have reviewed all information for the Troubled Health System case (made available to you in Week 1) completed the
Health Assessment (Week 1), along with your audit (completed in Weeks 2-3,), it is time to prepare your Audit Report.

Your report will be to the project sponsor who has several concerns:

1. What is the current state of the project

2. What are the root causes of the problems

3. What changes that need to be made (including rationale)

I have provided a sample from the author of our textbook as an example (ONLY!) to support the development of your audit report – as
the recovery project manager – use your own experience, the content we have covered in our core classes, and the information from
this course and the case study – to prepare your audit.

In the audit, be sure to include both the project and people issues. It is also important to examine the symptoms and identify the root
causes of issues encountered – use these roots to guide your recommendations. In addition to creating the actions that will be taken, be
sure to explain the rationale behind the steps you plan to take.

Once the recommendations are accepted, these will drive the development of the recovery plan (due Week 6 as your final). The
recovery plan is not part of this mid-term exam.

For the project side of the analysis, pull in your experience and learnings from the earlier courses in the curriculum.

When examining the people side of the project – consider the following:

1. In what stage of the five-stage team development model is this team and why do you assess it at this level?
2. What skills are present and what skills are lacking in the team – at both the individual and team levels?
3. What is your recommendation for this team? What actions do you recommend to move the team to its next stage of

development and why will these resolve the team issues?

As you explore conflict resolution leadership, consider the following?

1. What is the cause of conflict?
2. What strategy should you employ to resolve the conflict?
3. What leadership style for current stage of the team development (guiding, coaching, structuring, directing) do you

propose and why?

From a motivation and confidence perspective,

1. What motivation strategy do you recommend to develop cohesiveness in the team?
2. How will this be implemented

3. What guidelines can you put in place to know if this has resolved the troubled team issues?

Guidelines: Be sure to include any citations (as necessary) per APA 6th edition and references.

SUBMIT THE MIDTERM EXAM THROUGH THE TURNITIN LINK BELOW.