HBRC Journal (2017) xxx, xxx–xxx

Housing and Building National Research Center

HBRC Journal

http://ees.elsevier.com/hbrcj

FULL LENGTH ARTICLE

Projects’ issue management

Amr Mossalam

Housing and Building National Research Center, Egypt

Received 1 January 2017; revised 30 November 2017; accepted 14 December 2017

KEYWORDS Abstract Almost no project can be delivered smoothly without facing some obstacles and issues
Project issues; during its lifecycle from concept till closure. This inevitable topic of ‘‘project issue management”
Issue maturity; did not attain the appropriate attention either in the literature or in the project management stan-
Issue index; dards or implementation practices. This paper explores the current awareness status and level of
Proximity; implementation of the topic within the project management environment. The conducted survey
Issue management process revealed that this topic is immature and needs to be fostered through awareness, training, institu-
tionalizing, automation and finally standardization. Within this context, a process flow is suggested
to be a standard operating procedure to deal with issues during projects implementation. This flow
is then verified and validated. To reinforce the topic, an index was newly developed and validated to
show the status of issues within projects with the aim of inclusion of this index within the overall
project health indicator. Finally, new knowledge area was suggested in a similar way of the Amer-
ican international standard of project management (PMBOK) as an initial trial for the PMBOK
update process every four years. The local and international impact of having such a topic ‘‘project
issue management” within projects was discussed showing some areas for implementation.
Ó 2017 Housing and Building National Research Center. Production and hosting by Elsevier B.V. This is
an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/).

Introduction and research methodology satisfactory resolution for the project to proceed as planned
and generally requires decisions to be made that are outside
Faced with limited budget, smaller staffs, shorter deadlines, the scope of day to day project tasks” [1]. In projects, the
more demanding stakeholders and more stresses to get projects sources of issues are very wide. For example: (1) Cost, scope,
done successfully, projects are overwhelmed with many techni- time schedules, materials, targeted benefits; (2) Dependencies,
cal, functional or business related events (issues) that arises business as usual/operations, resources, products; (3) Stake-
during their course and need satisfactory resolution. While a holders, organization, and project staff; (4) Anything that
‘‘project risk” is defined as: uncertain event or condition that arises from projects that can’t be immediately resolved.
if occurs has a positive or negative impact on a project’s Despite of the impact of ignoring project issues, the topic did
objectives. The definition of an ‘‘issue” is: ‘‘any project related not gain the required attention in project plans, manuals, or
event that arises during the course of a project that requires a international standards. As per the Project Management
Institute (PMI) standard for project management [2], the topic
is slightly tackled in chapter (10) ‘‘communication manage-
E-mail address: amossalam@gmail.com ment” and chapter (13) ‘‘stakeholder Management” through
Peer review under responsibility of Housing and Building National the issue log which is considered as an input to some processes
Research Center.
https://doi.org/10.1016/j.hbrcj.2017.12.001
1687-4048 Ó 2017 Housing and Building National Research Center. Production and hosting by Elsevier B.V.
This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/).

Please cite this article in press as: A. Mossalam, Projects’ issue management, HBRC Journal (2017), https://doi.org/10.1016/j.hbrcj.2017.12.001
2 A. Mossalam
within these knowledge areas. As reported by Martin [3], issues
can prevent attainment of project objectives/deliverables.
Other authors [4] searched this topic but from the software
industry perspective and focused on the issues resulting during
the software development. James [5] proposed an issue man-
agement plan that contained a suggested process flow with
specific roles and responsibilities, While QNPM [6] suggested
two types of processes (simple and complex) based on the size
of the project. As reported by ESI [7], monitoring issues logs is
one of the many metrics and reporting techniques that grant
stakeholders visibility into the progress and challenges of the
development effort. Michigan University has reported [8] that
since an issue is a problem that has already been realized, it can
no longer be mitigated, and must instead be resolved. He
reported also that issues may have started from risks that have
been realized; if this is the case, then the issue should be linked
to the original risk. To track the progress of the issues resolu-
tion, Mind [9] suggested having a clear label identifying the
issue’s overall status. These labels are: open, Investigating,
Implementing, Escalated, and Resolved. As per the Practice
American standard for Project Risk Management [10],
issues/problems entail project management actions that are
outside the scope of the Project Risk Management process
[11] used an issue matrix (Fig. 1), similar to the traditional risk
matrix to provide an overall issue rating that takes into
account the timing of the realized impacts. However, instead
of probability (in the case of risk matrix), the rows relate to
ranges of time in which the issue needs to be resolved before
the impact negatively affects the success of the project.
Therefore, the literature and the preliminary observations
of the projects’ environment necessitate the need to deeply
investigate the topic using a structured approach. Conse-
quently, the methodology will be as follows: surveying a sam-
ple of projects to identify gaps in managing project issues, then
suggesting an issue management process flow followed by a
verification of the suggested process flow (survey and inter-
viewing). In addition, a metric to measure project issues is
developed and then checked by a parametric study. The mod-
ified process and the metric were both validated through actual
implementation. Finally, a new knowledge area for issue man-
agement to be incorporated in the international project man-
agement body of knowledge (PMBOK) was suggested.
The survey
To check the projects’ environment and how issues are han-
dled during the day to day activities, a survey was conducted
with the aim of identifying the following: (1) The awareness
level of issue management within projects, (2) The level of
implementation, (3) The comprehensiveness and maturity of
implementation for those who have this practice. The targeted
Fig. 1 Issue rating matrix [11].
Please cite this article in press as: A. Mossalam, Projects’ issue management, HBRC Journal (2017), https://doi.org/10.1016/j.hbrcj.2017.12.001
sample focused on those organizations having variety of pro-
jects to execute their approved strategy. The sample size
needed was 94 (confidence level of 95% and confidence inter-
val of 10). (Sample size = Z2 * p * (1
p)/C2, where Z =
1.96 for confidence level of 95%, p = 0.5 percentage picking
a choice, and C = 0.1 confidence interval). The responses
received were 124 out of 221 distributed (i.e. 56%) showed a
good variety of organization type (26% Construction firms,
11% IT firms, 6% consultants, 18% employers, and 41% gov-
ernment organizations). Their projects types varied among
design, construction, IT, railway, infrastructure, roads,
bridges, parks, and restoration projects. This mixture covers
a big portion of the project types’ spectrum.
Out of 124 responses, 43 are engineers, 23 are project man-
ager, 18 are designers, 16 are senior engineers, 6 are residents
engineers, 5 are managers and 13 are not specified.
The first question measures the awareness level of the
respondents about the definition of issues ‘‘How do you define
project issue?”. Four choices were listed: (a) A risk in the pro-
ject, (b) An event that caused/may cause an effect to the pro-
ject, (c) A potential event that may affect the project, and (d)
An evolving risk having positive impact. The results showed
that 45.9% of the respondents got the right answer (answer
‘‘b”). The second highest score was 23.4% for choice ‘‘c”
which actually was the definition of a ‘‘Risk”. These percent-
ages indicate that approximately 54% of the sample do not
have the right definition of a project-issue and the apparent
misunderstanding between issues and risks. Does your organi-
zation have a documented procedure/or guide for handling
project issues? This was the second question. The results ran-
ged between 8.1% (Yes) and 91.9% (NO) indicating that the
majority of organizations have no procedure/or guide to man-
age their project issues. The reason for the ‘‘NO” percentage
(91.9% above) was further investigated through the next ques-
tion: (In your opinion, the reason for not having such a proce-
dure/manual/guide). The four offered options were: (1) Not
important, (2) Issues can be dealt in day-to-day activities, (3)
No well-recognized standard that addresses the importance
of this topic, and (4) Lack of awareness. The results revealed
that almost 25% considers this topic as a normal activity that
can be managed in the daily project tasks. 11.3% attributed
this to the lack of awareness while the majority (54.8%)
referred the reason to the lack of a standard. The first two per-
centages show the need for having comprehensive training
especially in the project management field to increase aware-
ness and change the concept of dealing with issues on an ad-
hoc basis. For those who said ‘‘Yes (8.1%) as per question
‘‘2” shown earlier” for having a procedure for Issue Manage-
ment, and to check the level of implementation, the respon-
dents were asked: Do you apply this procedure/guide to your
project(s)? The answers revealed the following implementation
percentages (60%: Yes, 20%: No, 20%: sometimes). These
percentages indicate that those who have a system for manag-
ing the issues have a moderate level of commitment in imple-
mentation. The features of the implemented issue
management system in those organizations were explored
through the following questions (the respondents were asked
to tick whatever applies to their Issue management system –
if any): (1) Are there any criteria to define what an issue is?
(Yes = 10%), (2) Is there an ‘‘issue owner” log? (Yes =
70%), (3) There is a scale to rank issues as (High – Medium
– Low)? (Yes = 60%), (4) If the issues are not solved, is there
Projects’ issue management 3

an escalation scheme to escalate the issue to higher decision
levels? (Yes = 10%), (5) Does the reporting requirements of
project issues are well defined? (Yes = 40%), (6) Is there any
automated tool to handle ‘‘project issues”? (Yes = 0%). To
check the maturity of this implementation, 100% of the
responses declared having no methodology/tool to assess the
level of maturity for project issues. Finally, the usage of ‘‘is-
sues” in measuring the overall performance of the project (pro-
ject status) was explored. Among the Time, Cost, Risk, Issue,
Quality, and Safety; the answers ranged between a maximum
of 100% for time and a minimum of 0% for issues (for other
factors: cost is 10%, risk is 20%, quality is 10%, and safety is
40%).
In conclusion, the survey showed the need to increase
awareness of project teams with the right definition of issues
and how to differentiate it from risks and make the required
paradigm shift for those who consider issues as something that
need no planning or controlling. This could be attributed to
the low percentage of organizations having operating proce-
dures to manage project issues. The need for an international
standard that addresses the issue management was one of the
reasons for not having such operating procedures. These orga-
nizations who apply this system commonly use the issue log as
the main and only tool to manage the topic. Finally, there is a
noticeable need for having automated tool to manage issues
which will enhance the implementation maturity level.
process flow. The results showed that 70% agreed with the sug-
gested flow as is, while 30% gave some comments. These main
comments were: (1) The process flow is easy and simple (no
action will be taken), (2) The process flow followed the full
cycle of (Plan-Do-Check-Act) (no action is required), (3) There
could be a project change as a result of issue responses and this
should be reflected in the process flow. (i.e. the process flow to
be amended), (4) There is no measurement of the effectiveness
of the decided responses (i.e. the process flow to be amended).
As a result, the process flow was amended to reflect the feed-
back attained by the survey. Fig. 2 shows the modified process
flow where three steps (yellow marked) were added to the chart
namely: checking the need for a change, raising the change
request if needed, and checking the responses effectiveness
The modified process flow was introduced to the subject mat-
ter experts through one to one interviews, which is the second
verification method (interviewing). An Average of 20-min
interview was conducted with four subject matter experts to
present the results of the verification survey and the modified
process flow. Their major feedbacks were: (1) They agree with
the comments attained in the survey and (2) They recommend
having a score to measure the project issue index and be
included in an overall project performance indicator. The fol-
lowing paragraphs show the efforts done to develop a metric
for measuring the project issue status and how this metric
was checked for sanity.

Suggested project issues process flow and verification Developing a metric to monitor project issues

Table 1 and Fig. 2 (without highlighted boxes) show the steps
of the suggested process of issue management.
To verify the process flow, two methods of verification were
followed. Firstly, a verification through another survey target-
ing the originally surveyed sample. Secondly, interviewing with
subject matter experts to get their feedback. For the first
method of verification (re-survey), those 8.1% organizations
(who have procedures for issues – as previously reported) were
approached through another survey. The responses collected
represent 100% of the approached respondents. The survey
was simply structured to allow respondents to either agree with
the suggested process flow or not. The 2nd part of the survey
was an open ended question to allow for commenting on the
To establish ‘‘project issue index”, the literature [12,13] showed
that there is a similar index used for monitoring project risks.
This risk index is calculated through the ‘‘severity” of the risk
impact. i.e. having a value for each risk depending on its
impact: (Major impact = 0.9, Moderate = 0.6, Minor =
0.3), then calculating the overall risk index by getting the aver-
age of: impact multiplied by probability for all project risks.
Similarly, the Issue severity is suggested to be measured using
same method. See Table 2.
To reduce the subjectivity in the previous score, the author
suggests adding a new parameter to be used in conjunction
with the issue severity index. This parameter is the ‘‘proximity”
which can be considered as important as the severity.

Table 1 Description of the process flow steps.

# Step Purpose
1 Plan issue management Development of a plan showing the methodology of how to do each of the following steps
2 Identify issues Determine the current issues facing the project using the different sources of information
3 Categorize issues Classify issues according to their disciplines (civil – mechanical – electrical – time – cost –
materials. . .)
4 Assess impact Determine the impact of the issues on time and cost of the project
5 Prioritize (high – medium – low) Prioritize issues according to their impact severity (high – medium – low)
6 Need to escalate? A checking step for the team ability to handle issues or to escalate
7 Escalate with recommendation If escalation is selected, it should be accompanied by specific recommendations
8 Determine response and To determine the required responses for each issue in addition to assigning responsibilities
responsibilities
9 Communicate responses Communicate the tasks assigned to different team members to handle the issue and other
stakeholders
10 Monitor responses Control the implementation of planned actions
11 Close issues A step of final closure and updating the relevant documents

Please cite this article in press as: A. Mossalam, Projects’ issue management, HBRC Journal (2017), https://doi.org/10.1016/j.hbrcj.2017.12.001
4 A. Mossalam

Plan issue Plan Issue

management Management

Idenfy Project
Idenfy issues
Issues

Categorize Issues
Analyze issues

Assess Impact

Priorize Issues

Need to
Yes
escalate
Plan issue responses Escalate with
No recommendaon

Determine Responses
and Assignments

Change
Yes
Required

No Raise Change
Communicate Request
Control issues Responses

Monitor Responses

Check Effecveness

Close Issue

Fig. 2 The issue management process flow after modification.

Generally, when we have an issue, it has a response date after

which the issue will be critical for the success of the project.
The duration between the current date and the response due
Table 2 Calculation example of issue severity (dummy
values).
date is a vital factor. In other words, the closer the response
due date to the project closure date, the worse for the project
Issue # Severity Severity score as this could extend beyond the end date. In other words, in
i1 Moderate 0.6 most cases, the earlier the solution of issues, the better for
i2 Minor 0.3 the project and vice versa. To derive the formula to calculate
i3 Minor 0.3 the issue proximity, we will normalize the difference between
i4 Major 0.9 (Response Due Date & Current Date) of project issues by
Average 0.525 relating this difference to the total remaining duration till the
project end (Project End date – Current Date) (Fig. 3).

Please cite this article in press as: A. Mossalam, Projects’ issue management, HBRC Journal (2017), https://doi.org/10.1016/j.hbrcj.2017.12.001
Projects’ issue management
Fig. 3 Current, response, and project end date timeline.
Transferring to a formula : Issue Proximity
ðResponse due date
Current dateÞ
¼
Total days remaining till project end
ðResponse due date
Current dateÞ
¼ ð1Þ
ðProject end date
Current dateÞ
The resulting decimal number of Proximity is another fac-
tor to be taken during monitoring of project issues and getting
a value for issue index using the following formula:
ðSeverity þ proximityÞ
Issue Index ¼
2
Parametric sanity check for the proximity index
To check the sanity of the proximity index, the variables con-
stituting the index will be tested for all possible cases. For each
case, the proximity value is shown with the corresponding
explanation and the required action to be taken to handle
the case. As previously stated, the suggested Proximity index
has the following formula:
X ðResponse Due date
Current DateÞ
Issue Proximity ¼ ¼ Audits, Stakeholders log, and Procurement documents. Two
Y ðProject ENd date
Current DateÞ
ð3Þ
The test cases in Table 3 will check the sanity of the formula
when the numerator (X) is equal to
zero, or the value of dom-
inator (Y) is a negative value, or XY
is equal to 1.0 (see Fig. 3)
and many other cases as shown after.
As seen from Table 4, different cases could happen during
the monitoring of project issues, however the value of the for-
mula used to calculate the proximity will turn to either a dec-
imal number or a value of one. To get the Issue index, the
resulting value of Proximity is combined with the Severity
number (0.9, 0.6, or 0.3) getting the average using Eq. (2) pre-
viously shown. To get the project index; formula (2) is repeated
for all active issues. i.e.:
Project Issue Index ¼ Average score for all active issues
The following thresholds and traffic lights colours can be
used (or any other appropriate scale) for any single issue or
the overall status of project issues. High issue – red colour –
when Issue index is >0.6 while it is green coloured for values
<0.3 (low). In between, it is medium and gets an orange col-
our. Table 4 shows sample dummy calculations which need
some automation efforts to easily attain results and coloured
notifications.
Please cite this article in press as: A. Mossalam, Projects’ issue management, HBRC Journal (2017), https://doi.org/10.1016/j.hbrcj.2017.12.001
5
Validation
To implement the suggested process flow and the project issue
index to have actual implementation results, seven project
managers were approached. Only two managers agreed to
implement. The rejection was attributed to: (1) The project is
in its midlife and new concepts are not welcomed, (2) The issue
management is not part of the project management plan, (3)
This new topic needs long-approval process of the project
Consultant before implementation, (4) Project issues are confi-
dential, and (5) This method may show an unwanted status of
ð2Þ the project. The two-implementation projects were in Dubai
and of construction nature, one is rail type and the other
was a road construction. both were in the execution phase.
The issue process flow was implemented in both projects
with the assistance of the project risk coordinator with consent
of the project manager. The project team and the author devel-
oped an issue log that contains the following: issue brief name,
issue description, type, action by, actions required, and due
date. These fields would facilitate calculating the issue index.
The identification of issues was performed using many
resources within the project, such as: Progress reports, Project
assumptions and constraints, Quality related reports, Risk log,
issue lists were compiled (83 and 49 issue items respectively
for the two projects). Fig. 4 shows a sample calculation of
the issue status index using both parameters; severity and
proximity. The indices for the two projects were 0.63 (high)
and 0.48 (medium) respectively. These values were communi-
cated through the different reporting systems to the relevant
project team members.
Results of validation ‘‘implementation results
The following implementation results were identified within
the aforementioned two projects.
(1) The highly ranked issues were a main agenda item in the
project progress meetings. (2) It was decided to have periodical
separate meeting called ‘‘critical issue meeting” to handle pro-
ð4Þ
ject issues and getting the project on track. (3) The continuous
monitoring of the issue log was a key to accelerate resolving
the issues. (4) The inclusion of high issues and their solution
in the project lessons learned log. (5) There was an extensive
discussion to have a complete dashboard for the project to
include all project indicators (time performance, cost, risk,
quality) in one unified indicator and to add the issue as a
new factor. The discussions ended having one project status
indicator consists of different weighted sub-factors (35% for
6 A. Mossalam

Table 3 Parametric sanity check for proximity index.

Case The check Recommendation Proximity index
# value
1 X = positive value (response date > current date) Still there is a period to respond to the required As calculated
actions (still open issue)
2 X = 0 (response date = current date) The response date is due – new deadline to be set 1.0 (to reflect
max value)
3 X = negative value (response date < current date) Missed response date and issue is still open – new 1.0 (to reflect
deadline to be set max value)
4 Y = positive value (project end date > current date) Project still ongoing – no action As calculated
5 Y = 0 (project end date = current date) Project is closed – all open issues should be 1.0 (to reflect
comprehensively checked and acted upon max value)
6 Y = negative value (project end date < current date) Project is closed – the current stage is in the defect 1.0 (to reflect
liability period – open issues should be escalated max value)
X


7 Y = 1.0 (response date = project end date) Check issue closure – index value is max. – immediate 1.0 (to reflect
actions to close the issues or escalate max value)
X


8 Y > 1.0 (issue response date extends beyond project end
Set a new deadline within the project duration 1.0 (to reflect
date) max value)
X


9 Y
< 1.0 (Normal case)
Issue is open – monitoring to be continued As calculated
10 X New deadline to be set 1.0 (to reflect
Y = 0 (same as case 2)
max value)
X


11 Y = infinity (i.e. Y = 0, same as case 5) Project is closed – all open issues should be 1.0 (to reflect
comprehensively checked and acted upon max value)
X


12 Y = negative value (either X or Y = negative value Issue is still open – missed response date – escalation is 1.0 (to reflect
(case 3 and 6 respectively)) required max value)
X

0


13 Y = 0 = error (current date = response date =
Project is closing – all open issues should be urgently 1.0 (to reflect
project end date) checked and escalated max value)
14 Issue is solved and closed This is an objective to close all project issues. Both 0.0
values of proximity and severity will turn into zero for
this specific issue. Other issues still have their own
values of severity and proximity

Table 4 Sample calculation of issue index.

Proximity Proximity Formula

Issue Severity Status
formula Value Value
i1 0.6 0.0 1.0 0.8 High
i2 0.3 0.2 0.2 0.25 Low
i3 0.3 Negative 1.0 0.65 Medium
i4 0.9 0.9 0.9 0.9 High
issue index for the Project 0.65 (i.e. high)

time, 35% for Cost, 15% for quality, and 15% for both risks
and issues). (6) The Enterprise Project management office
(EPMO) in one of the two organizations started to automate
handling project issues through customization of its project
management tool. These results will be a good motive (when
properly marketed) for other projects to adopt the subject
and to start implementation.
The newly suggested PMI knowledge area
During implementation of the process flow, the author faced
many queries regarding the tools used, the required docu-
ments, and what is the expected result to be attained. Such
queries were the main reasons to start suggesting a process
which is similar to the PMBOK standard. The PMBOK
methodology in establishing the processes starts with describ-
ing the Inputs required to start the process, then the Tools
and Techniques that will be used to perform the process and
the Outputs resulting from the process. The five suggested pro-
cesses are: Plan Issue Management, Identify Issues, Analyze
Issues, Plan Issue Responses, and Control Issues. Firstly, the
‘‘Plan Issue Management” Process: This process will cover
the ‘‘how” for all the coming processes: how to identify the
project issues, how they will be analyzed for their impact,
how responses will be assigned, and how to monitor unre-
solved issues. The ‘‘Identify Issues” Process: The main target
of this process is to have a project issue list regardless their sig-
nificance. The next process (analyze issues) will take care of
prioritizing the issues. The ‘‘Analyze Issues” Process: In this
process, all captured issues will be analysed for their signifi-
cance and their impact (severity). The results will be a list of

Please cite this article in press as: A. Mossalam, Projects’ issue management, HBRC Journal (2017), https://doi.org/10.1016/j.hbrcj.2017.12.001
Projects’ issue management
Fig. 4 Example of the issue log for project # 1 showing issue index calculations.
Table 5 Inputs, tools and techniques and outputs for identify issues process.
Inputs Tools & techniques
 Progress and performance reports  Expert judgments
 Project assumptions and constraints  Meetings
 Risk log  SWOT analysis
 Audits  Root cause analysis
 Stakeholders log  Documentation review
 Procurement documents
ranked issues (high, medium, or low) and project documents
updates such as: top issues need escalation – issues needs
urgent actions. The ‘‘Plan Issue Responses” Process: this pro-
cess is to put alternatives and plans of the required actions.
These responses should satisfy the criteria of: be proportionate
with the issue severity, time bounded, and have agreed-on pro-
cedures. Finally, the process of ‘‘Control Issues”: it is for mon-
itoring if the responses is carried out. It also includes
monitoring the effectiveness of the actions taken. Table 5
shows an initial list of Inputs, Tools, and Outputs for one of
the processes which can be further analyzed, checked and val-
idated in future researches.
Significance of this research
It is believed that the outcome of this research will result in
some considerable changes in the environment of project man-
agement as follows: (1) A change in project management poli-
cies within organizations, (2) Accurate project language
regarding the difference between Issues and Risks, (3) More
visibility for the problems and issues within projects, (4) The
topic to be added as a new module in the automation efforts,
(5) Shifting from traditional reporting of project performance
that depends on time, cost and scope to new indicators that
could reflect issues and soon; risks, (6) Highly-ranked issue
project will attain high attention of top management. This will
be the result of periodically reporting the issue index to man-
agement, (7) A suggested change in the knowledge areas of
the Project Management Body of Knowledge. i.e. adding issue
management as new area in this standard, (8) Suggesting the
proximity parameter to assess the issues beside the currently
Please cite this article in press as: A. Mossalam, Projects’ issue management, HBRC Journal (2017), https://doi.org/10.1016/j.hbrcj.2017.12.001
7
Outputs
 Issue list
 Change request (for urgent issues before analysis)
 Documents update
used one ‘‘severity”, (9) A suggested automation module to
be added to the commercially available softwares to increase
its effectiveness in managing projects, and (10) Adding the
issue management as a new criterion in assessing the maturity
of project management in organizations.
Conflict of interest
The authors declared that there is no conflict of interest.
Acknowledgements
The author would like to express his deep thanks to Dubai
roads and transport authority (RTA) which facilitates and
provided valuable data inputs to the research.
References
[1] A. Schuchat, Issue management. CDC unified process practice
guide, 2006.4. pp. 1–4.
[2] M. Langley, Stakeholder Management. PMI lexicon of Project
management terms, fifth ed., Project Management Institute Inc.,
Pennsylvania, 2012.
[3] W. Martin, How to Manage Project Issues. Leadership
thoughts, 2014. Accessed Dec. 2014.
[4] L. Robert, Glass, Issue management, Database for Advances in
Information Systems, vol. 29(4), 1998.
[5] James Green, Project Issue Management Plan, Commonwealth
of Massachusetts Information Technology Division, 2009, pp.
1–12.
8 A. Mossalam

[6] Q. NPM. Issue Management Plan Preparation Guidelines,
Qatar National Project Management, 2010.
[7] ESI, Metrics for Agile Projects: Finding the Right Tools for the
Job, ESI International Inc., 2010.
[8] M. NextGen, Project Management Handbook, University of
Michigan, Michigan Program: accessed Mar. 2015.
[9] Project Issue Management. Identifying and Resolving Issues.
<http://www.mindtools.com> accessed on Oct. 2014.
[10] M. Langley, Practice Standard for Project Risk Management,
first ed., Project Management Institute Inc., Pennsylvania, 2009.
[11] www.mosaicprojects.com.au. Issue management. Accessed Feb
2015.
[12] R. Mulcahy, PMP Exam Preparation, eighth ed., RMC
Publications, USA, 2013.
[13] J. Greene, A. Stellman, Head First – PMP, second ed., O’Reilly
Media, USA, 2009, pp. 543–601.

Please cite this article in press as: A. Mossalam, Projects’ issue management, HBRC Journal (2017), https://doi.org/10.1016/j.hbrcj.2017.12.001