Improving the Reporting Practice in Project Delivery of Offshoring Projects Mika Loponen

Improving the Reporting Practice in Project Delivery of Offshoring Projects Mika Loponen
Mika Loponen
Improving the Reporting Practice in Project
Delivery of Offshoring Projects
Helsinki Metropolia University of Applied Sciences
Master’s Degree
Industrial Management
Master’s Thesis
11 May 2015
Preface
When I started to write this part of the thesis, I couldn’t stop thinking about the starting
point of my studies in Industrial Management in autumn 2014. A lot of things have happened between these two events and, not the least, a considerable professional growth
gained from the studies. This journey was an exploration of my company’s business as
I did not only learn a lot from the case company, but also was able to form a new perspective to better see the activities and business of the case company. My company
supported me in my studies in an exemplary manner, great thanks for this all my colleagues who were involved for the contribution.
In the beginning of the studies, the topic of the thesis seemed to be very clear, but during this journey it turned out to be a challenge. The most challenging part of the thesis
was my ability to simplify things, to see the forest from the trees, especially when it
comes to choosing the right and potential focus for the study. Therefore I would like to
thank Dr Thomas Rohweder for helping me to get ahead from this most challenging
point when forming my conceptual framework. I also would like to thank PhL Zinaida
Grabovskaia, whose steering and encouragement were invaluable during my writing
process, and Dr Marjatta Huhta, Head of Program, for her vital comments and keeping
up a positive, encouraging and creative atmosphere throughout the academic year.
Last but not least, this thesis would not be completed without extensive support from
my family and friends, special thanks to my wife and children for making this possible.
Mika Loponen
Helsinki, 11 May 2015
Author
Title
Number of Pages
Date
Mika Loponen
Improving the Reporting Practice in Project Delivery of Offshoring Projects
71 pages + 9 appendices
11 May 2015
Degree
Master in Engineering (MEng)
Degree Programme
Industrial Management
Instructors
Marjatta Huhta, DSc (Tech), Principal Lecturer
Zinaida Grabovskaia, PhL, Senior Lecturer
This thesis investigates reporting practice in the case company and proposes improvements on it. The case company uses offshore for project operations and recently use of
offshoring has been increased significantly. Due to growth in offshore operations some
reporting practices has not been developed accordingly.
The research method of this thesis was action research due to its cyclical and qualitative
nature, which was considered to serve best the needs of this study. The research design
includes five steps, where the business problem identification, the current state analysis
and the conceptual framework combines an input for building and finalizing the proposal.
As a result of the current state analysis, three main challenges were identified in order to
form conceptual framework, and further on, to build the proposal for the case company.
The challenges were categorized into three logical questions related to the more general
problems of reporting for further examination in the literature. The categorized questions
were: a) what to report, b) how and when to report, and c) by what means to report.
The outcome of this thesis is the improvement proposal on reporting practices in the project delivery of the case company. The proposal identifies three problematic areas in reporting practice in the case company and suggests the improvement proposal, including
the action plan, on each of them.
The suggested improvements on the current reporting practice includes: First, the new
weekly report template for offshore reporting. This report template serves the project team
as well as the customer. The report template creates the conditions for more formal and
uniform reporting between onsite and offshore and saves time as part of the data can be
reused further on when reporting the status to other reporting lines. Second, the improvement suggestions to the project accounting tool in order to ease the use of the tool, to confirm the accuracy of data provided by the tool and to align data from the tool with the current health check report of the case company. Third, to improve the current financial report
by adding few additional data fields into the report in order to ease use of the report and
save time.
The outcome of this thesis helps the case company to clarify their reporting practices. The
case company may benefit from the results of this thesis by more uniform, more accurate
and time saving reporting practice.
Keywords
Reporting practices, project management, portfolio management, reporting tools, offshoring, project delivery
Contents
Preface
Abstract
Table of Contents
List of Figures
List of Tables
1
2
3
Introduction
1
1.1
Case Company Background
1
1.2
Key Concepts
2
1.3
Business Challenge
3
1.4
Objective and Scope
3
Method and Material
5
2.1
Research Approach
5
2.2
Research Design
6
2.3
Data Collection and Analysis
7
2.4
Validity and Reliability Plan
11
Current State Analysis
13
3.1
Overview of the Offshore Projects in the Case Company
13
3.2
Mapping of the Current Processes
15
3.2.1
Work Order Process
16
3.2.2
Project Delivery Process
18
3.3
Challenges in the Current Work Order and Project Delivery Processes
21
3.3.1
Key Problems of the Work Order Process
22
3.3.2
Key Problems of Project Delivery Process
25
3.4
Summary of Current State Analysis (Two Processes) and Focus Areas
27
3.5
Examination of the Challenges in the Current Reporting Practices
30
3.5.1
Map and Description of the Current Reporting in the Project Delivery
30
3.5.2
Identification of Improvement Needs in the Current Reporting
31
3.5.3 Summary of Key Findings from the Current Reporting Practices in
Project Delivery
34
4
Existing Knowledge in IT Project Reporting
36
4.1
36
Overview of Project Reporting as Part of Project Management
4.2
4.3
5
Project Control in IT Projects
37
4.2.1
Schedule Control
38
4.2.2
Cost Control
39
4.2.3
Quality Control
40
4.2.4
Productive Control
41
Project Monitoring and Reporting as a Continuous Process
41
4.3.1
Project Portfolio Management Team
42
4.3.2
Steering Group
43
4.3.3
Project Manager
45
4.4
Reporting Practices
47
4.5
Conceptual Framework of This Thesis
51
Building Proposal for the Case Company
53
5.1
Challenges in the Current Reporting Practice
53
5.2
Reporting Improvements and Suggestions from Team Discussions
55
5.3 Action Plans for Implementing the Improvement Suggestions in Reporting
Practices
59
6
7
Validation of the Proposal
63
6.1
Validation with the Management
63
6.2
The Final Proposal
63
6.1
Managerial Implications
65
Discussion and Conclusions
67
7.1
Summary
67
7.2
Practical Implications and the Next Steps
68
7.3
Evaluation of the Thesis
69
7.3.1
Outcome vs Objective
69
7.3.2
Reliability and Validity
70
7.4
Final Word
References
Appendices
Appendix 1. Summary Project Forecast Report
Appendix 2. Project Time Forecast Report
Appendix 3. Cost Forecast by Type Report
Appendix 4. Cost Forecast by Product Report
Appendix 5. Project Quality Forecast Report
Appendix 6. Benefits Forecast Report
71
72
Appendix 7. New Weekly Report Template
Appendix 8. The Current Project Accounting Tool
Appendix 9: The Estimates and Financial Tabs of the HC Report
List of Figures
Figure 1. Action research process (Lewin 1958). .......................................................... 5
Figure 2. The research design in this study................................................................... 6
Figure 3. Project organization structure. ..................................................................... 14
Figure 4. High level description of the main processes. .............................................. 15
Figure 5. The work order process. .............................................................................. 16
Figure 6. Project delivery process in the case company. ............................................. 19
Figure 7. The current challenge areas in the work order process. ............................... 27
Figure 8. Identified problematic parts of the project delivery process. ......................... 29
Figure 9. The current reporting map in the case company. ......................................... 31
Figure 10. Summary Tab of the Project Accounting Tool. ........................................... 32
Figure 11. The financial forecast report. ...................................................................... 33
Figure 12. Focus areas and main questions from the current state analysis. .............. 35
Figure 13. Project progress data managing (Roberts 2007: 178). ............................... 46
Figure 14. The project register report (Roberts 2007: 172). ........................................ 48
Figure 15. An overview of the portfolio (Roberts 2007: 175). ...................................... 50
Figure 16. Conceptual framework of this study. .......................................................... 52
Figure 17. Reporting lines and cycles in the case company. ....................................... 54
Figure 18. Mapping of suggested solutions. ................................................................ 61
Figure 19. The schedule for implementing the suggested proposals. .......................... 65
List of Tables
Table 1. Data sources in this study. .............................................................................. 7
Table 2. Data 1. Details of the Interviews and discussions. ........................................... 8
Table 3. Data 1. Topics for the interviews. .................................................................... 8
Table 4. Data 1. Analyzed internal documents of the case company. ........................... 9
Table 5. Description of WO-process steps. ................................................................. 16
Table 6. Description of the project delivery process steps........................................... 20
Table 7. Distribution of findings from interviews. ......................................................... 22
Table 8. Most significant observations in the work order process. ............................... 23
Table 9. Most significant findings in the Project Delivery process. .............................. 25
Table 10. Project reporting challenges in the case company. ..................................... 34
Table 11. Descriptions of the details in forecast reports (Roberts 2007: 181,182). ...... 44
Table 12. Project manager’s responsibilities (Moustafaev 2010). ................................ 45
Table 13. The project register report details (Robert 2007). ........................................ 49
Table 14. Project reporting challenges in the case company. ..................................... 53
Table 15. Suggestions for solving the current reporting challenges. ........................... 58
Table 16. Action plan for implementing the uniform report template for offshore
reporting. .................................................................................................................... 59
Table 17. Action plan for improving the Project accounting tool. ................................. 60
Table 18. Action plan for improving Finance forecast report. ...................................... 60
Table 19. The final proposal, shown as three outcomes. ............................................ 63
1
1
Introduction
Emerging markets, especially some Asian countries, offer well educated and highly
skilled labor for IT companies around the world. Some companies want to take advantage of the available knowledge in these countries and have established cooperation with companies in Asia. However, long term advantages can be ruined by
negligent planning and implementation of offshoring projects. Success in offshoring
calls not only for good planning of the target state, but also for awareness and careful
delivery in daily processes, so that the impact of offshore collaboration will be positive,
beneficial and leads to profitable operations for the company. Such daily matters, however, involve numerous aspects, visible across many processes in project management
of offshoring projects.
1.1
Case Company Background
The case company is a medium size company offering IT-services to the financial sector. It employs around 200 people in Finland and has offshore locations in Poland and
India. The case company is part of a bigger international IT service provider which will
be treated anonymously in this study due to confidentiality reasons.
The case company has two main business lines which are project delivery and service
maintenance businesses. Service delivery business line includes Project Delivery business being responsible for IT-solutions sales and delivery to a customer. Quite often
the Project Delivery process is extended with service maintenance once a project is
completed and delivered. If so, then service maintenance business takes over from the
delivery business and starts to maintain service according to the ITIL. The service
maintenance business line covers IT-service maintenance and minor development of
systems. Thus, two main processes of the project delivery business are Work Order
and Project Delivery processes. These processes are sequential so that the Work Order process, which is dedicated to preparing quotation for the customer, is followed by
the Project Delivery process in case the customer has accepted the quotation.
The case company started to use offshore in 2014. During the year 2014, the amount
of offshore usage especially in Project Delivery and consultation business, has in-
2
creased, and now offshore has gained a significant role in the company business and
strategy.
1.2
Key Concepts
In general terms, offshoring means the relocation of a business process from one
country to another country. Business processes typically relocated in offshoring, for
example, in the IT industry, are software development or testing functions. According to
experts, the most important reasons for moving business out of the U.S. are lower
wage rates in the destination country, proximity to the customers and better access to
skilled labor (Porter and Rivkin 2012).
Project Delivery refers to delivering of a business outcome and according to Ditmore
(2011), it is one of the critical services in information technology. Project delivery typically consists of several practical areas that include project initiation, project communication and reporting, project management, release management, and program management (Ditmore 2011). In IT-industry, project delivery is often followed by IT service
maintenance handover, when the completed end results of the project are transferred
to the either organization or IT service provider. Then, the IT service maintenance organization maintains the solution developed in the project.
Project monitoring is a sequence of actions such as observation and supervision which
those in the management team should conduct in order to know the condition of their
projects. Without reporting it is not easy to monitor a project; moreover, without a sufficient level of monitoring the project, the risk level may increase. What makes reporting
significant and challenging is the fact that each level in the management hierarchy
needs information in a form and at a frequency that allows to exercise control and steer
the project effectively. It is also critical that such reports would show the extent to which
the project is likely to meet its completion expectations, giving any necessary data and
forecast set out in the project plan. (Roberts 2007: 170)
3
1.3
Business Challenge
This study focuses on improving efficiency of offshoring projects of the case company,
especially inefficiencies of the current operations in Project delivery of offshoring projects, related to ineffective reporting. When the company started to use offshoring, one
significant element of the offshoring projects was to have accurate and up-to-date information of each project progress. Currently, the case company have different levels
for reporting and all levels have different needs from reports. Although the company
has well-established reporting practices already before starting to offshore, some of
these practices and reporting tools faced new requirements coming from the growing
offshore business. That is to say that the use of offshoring calls for improvement of the
existing reporting practices for effective use in offshore projects.
One of such aspects in reporting is the steps and practices to accurately follow the project progress. As the strategy of the case company is now based on the use of offshore
workforce, it is clearly required to be aware of the actual status and clear forecast of
the upcoming phases of each project. In order to monitor the project progress effectively, the accurate and timely flow of information is essential. If the practices and tools are
not improved, the project monitoring may give a false picture of the project status. This
in turn has impact on business and, in the worst case scenario, bad quality of reporting
might jeopardize the business of the company or limit its financial success.
In order to deliver financially successful projects in the future, the company wants to
investigate the current status and find weak points in its project management in order
to streamline the current processes. The case company sees this improvement as a
factor which enables the company’s financial success in the future.
1.4
Objective and Scope
The objective of the study is to explore the current Work Delivery and especially Project
Delivery processes and some of their associated practices, and point to the most critical challenges in both processes. Based on the identified development areas, the thesis then concentrates on one direction which can realistically be improved to a positive
outcome, so that the case company can immediately benefit from the improved process or practice in its offshore projects. Therefore, this logic points to another, more
4
specified objective of the thesis, formulated as a result of the more focused approach,
following the initial investigation of the current process challenges.
The more specified objective of this thesis is unidentified as improving the current reporting practices in the Project Delivery process of offshoring projects. This objective
was identified as a result of the current state analysis on both processes, the Work
Delivery and the Project Delivery process, which involved extensive interviewing the
project personnel who are dealing with offshoring. The findings from the current state
analysis pointed to the reporting practices as the issues which call for immediate actions and, thus, became the specified objective of this study.
The outcome of this study is the proposal for improving three current reporting practices: (a) offshore project progress reporting, (b) portfolio management reporting tool, and
(c) the financial forecast report. They form the core of the current reporting practices in
the Project Delivery process. Thus, in the Proposal building part, the scope of the study
was limited to improving reporting, since it has proven to make an essential and challenging part of the Project Delivery business.
This study is divided into 7 sections. Section 2 describes the method and material used
in this study, including the research approach, data collection and analysis methods.
Section 3 describes the findings of the current state analysis. In this section, the current
offshore projects of the case company are overviewed and the current processes and
challenges analyzed. Section 4 discusses existing knowledge on offshore project management and knowledge management, specially focusing on reporting practices. Section 5 presents the proposal for the case company current processes. In Section 6, the
proposal is validated and the final proposal presented. Section 7 discusses and evaluates the results of the study.
5
2
Method and Material
This section discusses the research approach, methods and materials used in this
study. The section also presents the research design used in this study and also discusses data collection and analysis methods followed by validity and reliability plan.
2.1
Research Approach
This study uses action research as it research approach. Action research is orientation
of qualitative research methods. Action research pursues to develop the company, organization or other community under an investigation through their practices. Action
research is a cyclical process that includes three steps which are, according to Lewin,
planning, action and results. (Lewin 1958). This process is described in Figure 1 below.
Figure 1. Action research process (Lewin 1958).
As seen from Figure 1, the first step, planning, includes diagnosing of the problem
when unidentified problems becomes cognizant. The planning step includes also data
gathering and action planning and in addition to this it gets input from both action and
results steps for iterating of the preliminary diagnose of problems. The next step of action research is action, which continues developing action planning from the previous
step and strives to implement the planned actions in the organization. As an output of
the process results step gathers data from the actions implemented and based on that
evaluates implemented actions. This step can indicate any necessary adjustment
emerged in the evaluation back to either one of the previous steps via feedback (Coghlan & Brannick 2006). Cyclical nature of action research allows to running the process
through multiple times, and thereby improves quality of desired end result.
6
2.2
Research Design
In this study, research design is divided into six main stages which are the business
problem identification, the current state analysis, the theory and conceptual framework,
the preliminary proposal, the preliminary proposal test and validation and the final proposal. Figure 2 illustrates these main stages and data collection points.
Figure 2. The research design in this study.
Figure 2 shows the six stages of the research design in this study. The research design
starts with the business problem identification. The next step is divided into two parts,
the current state analysis, and theory search and building the conceptual framework.
The current state analysis gets input from Data 1 collection, which is described in more
detailed level in Section 2.3.
Theory and conceptual framework are discussed based on the current state results and
findings from the existing knowledge and theory. Both of these steps are prerequisites
for building the preliminary proposal.
The preliminary proposal will be created based on the Data 1 and Data 2, and it is followed by evaluation of it with the interviewed people from the case company. The preliminary proposal will be evaluated together with the management of the case company
and part of it will be tested practically in a real project. As a result of this evaluation and
testing, the preliminary proposal will be further developed into the final proposal describing how to improve efficiency of project delivery business. The final proposal in-
7
cludes recommendations and action plans on how to proceed with identified challenges.
2.3
Data Collection and Analysis
Data collection and analysis in this study is done using qualitative data and analysis
methods, such as documentation analysis, observations and interviews. This makes
difference with quantitative manner, which, in turn, focuses on numerical data. Data for
this study is collected from three main sources which are presented in Table 1 below.
Table 1. Data sources in this study.
Interviews and discussions
Internal documents
Observations







Uniform
interviews
with
people involved in project
delivery business
Meetings
Informal discussions
Process descriptions
Project documentation
Reports
Experience of personnel used for identifying
and solving the problem in this study
Table 1 shows that the primary sources of data in this study included: (a) the interviews
and discussions, (b) internal documents, and (c) participant observations by the researcher. The interviews were conducted with the people who are involved in offshore
functions in the case company. More detailed information about the roles of the interviewed personnel, topics and interview technique will be described later in this section.
Additionally, part of the research data was collected from internal documentations such
as process descriptions, project documentation and reports, and was also drawn from
the participant observations by the researcher who act as a project manager in the
case company offshoring projects. A more details description of the data source is given below.
Interviews and discussions
Opportunities to collect data consisted of interviews and discussions in different meetings, for example, the project team meetings, business unit meetings and other regular
meetings; as well as informal discussions with people who are involved in offshore
functions in the case company. The interviewed people represent the Project Delivery
business in the case company and all of them have experience in offshore from at least
one ongoing project. Summary of details related to interviews, meeting and discus-
8
sions, information about participants, projects, interview dates and forms of documentation of the interviews, meetings and discussions is presented in Table 2 below.
Table 2. Data 1. Details of the Interviews and discussions.
Person
Role
Project
Date
Documented as
1.
Technical lead
A
17.12.2014
Recording and field notes
2.
Project Manager / Team
Leader
A
17.12.2014
Recording and field notes
3.
Team Leader
B
18.12.2014
Recording and field notes
4.
Director
A,B,C,D,E,F
18.12.2014
Recording and field notes
5.
Software Developer
A
18.12.2014
Recording and field notes
6.
Software Developer
C
13.1.2015
Recording and field notes
7.
Project Manager
D
15.1.2015
Recording and field notes
8.
Software Developer /
Technical Lead
A
22.1.2015
Recording and field notes
9.
Technical Lead
A
27.1.2015
Recording and field notes
10.
Software Developer
A, F
3.2.2015
Recording and field notes
11.
Release Train Engineer /
Project Manager
E
4.2.2015
Recording and field notes
12.
Test Manager
D, G
4.2.2015
Recording and field notes
Table 2 shows that totally 12 people were interviewed from 7 different projects. Roles
of the interviewed people presented typical roles in a project delivery business in the
case company. The interviews, meetings and discussions were conducted face-to-face
and the participants were prepared to the event beforehand by presenting the topics as
described in Table 3 below.
Table 3. Data 1. Topics for the interviews.
Topic
Tools
Knowledge Transfer
Cultural Differences
9
English Language Skills
Practices
Reporting
Free Topic(s)
Table 3 shows that level of the topics was high enough to include different viewpoints
from the interviewees and discussion participants. Depending on the background of an
interviewee, he or she had an opportunity to discuss other topics as well, and all the
interviewees were encouraged to discuss the problems they have noticed in the offshore projects.
At the end of each interview, the topics were revised and viewpoint of an interviewee
was verified. Although the interviewees discussed both processes, the Work Order and
the Project Delivery, most made emphasis on the Project Delivery business. However,
project managers and director were exception to this as they have vast experience
from both processes. In addition to the field notes, in each interview the voice recordings were collected and field notes taken.
Internal documents
A number of internal documents were analyzed for the current state analysis. List of the
analyzed internal documents are overviewed in the Table 4.
Table 4. Data 1. Analyzed internal documents of the case company.
Name of the document
Description
A
WO_Process.pdf
Work order process diagram and description
B
Project_Delivery_Process.xls
Description and diagram of the both delivery
methods used in the case company
C
Project X Monthly Status Report.ppt
Project X weekly report
D
Project X Weekly Status Report.ppt
Project X monthly report
E
Project X Internal Steering Group
Report.ppt
Project X internal steering group report
F
Project X Management Group Meeting Report.ppt
Project X management group report
10
Table 4 shows that most of the document sources include different reports. The letter X
in report file names refers to a name of a project and because the names of the projects are to be kept secret, the X refers to any project investigated in this study. The
reports from different projects provides with practical information of the challenges in
the particular project and cross-section of the project delivery business. Such challenges give perspective for discussions with the project personnel.
Data 2
Data 2 was collected from the meetings and workshops kept with both the interviewed
and other people from project delivery organization in the case company. Data 2 was
collected when building of the preliminary proposal was in progress. Thus, the meaning
of Data 2 collection was to receive feedback on the unfinished proposal and to ensure
that the proposal is developing in the right direction.
Data 3
Data 3 was collected when the preliminary proposal was presented to the management
of the case company. Purpose of Data 3 collection was to receive feedback and comments from the management and to do necessary corrections on the preliminary proposal in order to finalize it into the final proposal. Additionally purpose of Data 3 collection was to ensure the fit of the proposal to the case company’s reporting practice.
Observations
This covers all observations made in different project context. Such observations appeared for example in the events that are not intended to discover problems particularly
in the area of this study but generally in the project delivery context. Typical events
were for example training sessions or project specific workshops. Hence the observations are formed from pieces of information taken from different contexts under the project delivery business in the case company.
As for data analysis, the primary method of data analysis for this thesis was content
analysis. All findings from the voice recordings, internal document and observations
(Data 1-3) were analyzed, coded, grouped and recorded into the Excel spreadsheet. All
findings in the Excel were categorized by ascribing them meaning grouped under various problem areas, and finally into bigger thesis entities such as belonging to the process or development area, problem description and proposal suggestions.
11
2.4
Validity and Reliability Plan
Meeting validity and reliability requirements are necessary for any qualitative research.
Validity determines whether the research truly measures what it was intended to
measure or how truthful the research results are (Golafshani 2003: 599). Validity in this
study means taking into account the correctness and credibility of knowledge gained in
this research in descriptions, conclusions, explanations and interpretations and also
avoiding the researcher bias.
Validity of this study will be increased by taken into account the following actions. First,
the data collection process will be described on a detailed level. Second, the collected
data from interviews will be analyzed and validated together with interviewees. Third,
data will be reported in detail with use of direct quotes. Fourth, interviewed people and
management team of the case company will be involved in developing and evaluation
of the proposal. Fifth, theoretical congruence is part of the study as theory and conceptual framework brings existing knowledge in realm of the study.
According to scholars of qualitative research methods, reliability is described as an
assessment of whether the same findings would be obtained if the research were repeated, or if someone else conducted it. Reliability of research can be strengthen or
improved by. a) using different data sources, b) using different data collection tools, c)
applying established theory from one area to another, d) collecting data at different
time points, or e) using different researchers at different points of research (Quinton
and Smallbone 2006: 129-130).
Reliability of this study will be increased by paying attention to the following criteria.
First, the data collected in study will include at least three sources as described in Section 2.3. Second, to enable verisimilitude, the outcomes of the study will be discussed
widely with colleagues in order to challenge the solution. Third, the data will be documented and further analyzed with the interviewed people, thus enabling transparency
into data and end results from the analysis. Fourth, the researcher bias will be minimized by pursuing the interviewees to discuss extensively, interpret the data results
with the interviewed people, discussing the results and the proposal with many stakeholders in the case company and finally considering the rival proposals for the improvement solutions.
12
The preliminary proposal of this study will be validated with the key stakeholders in the
Project delivery process, including the team and the management of the Project Delivery business in the case company. Part of the validation will be to question the proposed improvements and suggest alternative solutions for the challenges in the existing practices. Validity of the outcome of the study is hereby planned to be discussed
extensively in the case company.
13
3
Current State Analysis
This section discusses the results of the current state analysis based on the findings
from interviews and other source material. Section starts by overviewing the project
delivery business in the case company. This is followed by description of two main processes and identifying the current problems in the processes. Finally, the section
summarizes the findings from the current state analysis.
3.1
Overview of the Offshore Projects in the Case Company
The case company operates in software industry and the company’s activities consist
of development and maintain of the information systems. The development, for the
most part, includes further development of the existing information system of the customer. A project, and the project delivery model, is the framework of the case company
for producing and delivering agreed end results to the customer. Typical project in the
case company is the further development of the existing information system of the customer, based on the customer’s business needs and obligations on the authorities.
In the case company, one essential part of the project delivery business is the use of
offshore services. In each project, the case company organizes an offshore team, according to the agreement with the customer. Even though the offshore team has its
own project manager in the offshore location, who takes responsibility of steering the
project group, the offshore team works closely with the onsite team.
The organization structure of a typical project includes two main parties; the customer
and the case company, with both organizations having their own project managers who
are responsible for running the project in their organizations. An essential part of the
project organization is a management group, which has authority to make decisions
such as accept changes to the project plan. The management group consist of the
people from both organizations such as project managers and stakeholders who have
typically roles of a business unit director, sales representative, development manager
and product manager. Figure 3 describes the organizational structure of a typical project.
14
Figure 3. Project organization structure.
As seen from Figure 3, in terms of the hierarchy, a direct subordinate of the management group is the ICT-steering group. This group consists of a smaller number of people than the management group, including only project managers from both organizations, development manager from the customer side and business unit director from
the case company. This group meets at least at the same rhythm with management
group and it is practically scheduled always shortly before the management group. The
idea to meet before the management group is to prepare the issues to be discussed
and report on their status at the management group meeting.
Project manager of the case company is in the center of all the action in the project. He
or she is responsible for running a project in the case company. This includes steering
the onsite project group and also the offshore project group through their project manager. In other words, the offshore project manager is obliged to report to the onsite
project manager. The onsite project manager reports to steering group, ICT-steering
group and management group as agreed upon project plan.
Finally, in the project groups, members in each project group are selected based on the
knowledge needed in the project. The most frequently needed roles are described in
Figure 4 (below). Project group members are typically involved in close interaction to
other group members during the project and this is emphasized between onsite and
offshore team members.
15
An organized and systematic structure of the project organization helps to distinguish
the different roles and responsibilities of each player in the project delivery. It is noteworthy that the model described above reflects the basic project situation where the
project participants are limited to two main factors; the customer and the case company. However, it is possible that a project consists of more than two main factors, meaning, for example, that other suppliers are involved in a project. Such a situation requires
extension of the project structure described above and usually it is designed and taken
into account in the beginning of each project.
3.2
Mapping of the Current Processes
This study explores two main processes in the project delivery business of the case
company. These two processes are important to the case company because the first of
those processes creates pre-requisites and paves the ground for the future project, and
the second one represents the realization stage of this project, as well as brings a possibility to negotiate with the customer on additional business opportunities during the
process. Both of these processes are described on a high level in Figure 4 below.
Figure 4. High level description of the main processes.
As seen in Figure 4, the key processes the project delivery business unit of the case
company are a) the Work Order process, which has set fixed duration, and b) the Project Delivery process, the duration which is specified on a case-by-case basis. The
Work Order process, illustrated on a high level in Figure 4 above, takes place once the
customer indicates the request for proposal. The Project Delivery process will start in
the case when the customer has accepted the proposal which makes the end result of
the Work Order process. Next, two sub-sections describes the current state of the two
processes in more detail.
16
3.2.1
Work Order Process
The current Work Order (WO) process involves the activities to be taken day by day
from the customer indication and request for quotation until the final version of the proposal. The process lasts fixed duration and during that period of time the final proposal
for the customer should be finalized and delivered to the customer. Figure 5 describes
the main steps of the process on a high level and Table 5 below describes all the steps
in more detail.
Figure 5. The work order process.
As seen from Figure 5, there are three main roles involved in the Work Order process,
which are the project domain managers from both the customer and the case company
sides, and the solution team of the case company. The project domain managers will
involve other parties during the process if needed, but the project domain manager of
the case company gathers the required solution team that is responsible for creating
the actual solution and work estimates based on input of the customer. All steps of
WO-process are described in more detail in Table 5 below.
Table 5. Description of WO-process steps.
Process step
Description
17
1. Start
The process starting point.
2. Fill in / update work order request
The customer initiates the WO-process by
filling in a work order request.
Key parameters of the work order request and
other initial documentation will be reviewed.
Handover process can be completed once all
the initial documents are reviewed and they
include enough data for solution and work
estimation. Calculation of the duration of the
process starts once the handover process is
completed successfully.
Possibility to iterate initial documentation in
the case they are not descriptive enough, so
handover process cannot be completed as
long as there is not enough data.
This step includes creation of solution and
work estimation based on initial documentation reviewed in earlier step.
Common review of the solution and estimation.
In case some part of the solution and work
estimation needs clarification, or there are
other open issues, they will be solved. If
there’s no any open issues, process progress
to the next step.
In this step open issues from review of solution and estimate step will be solved.
3. Review work order request
4. Handover process
5. Is there enough data for WO
6. Draft initial version of solution and
work estimate
7. Review solution and estimate
8. Are there open issues
9. Resolve open issues and update solution
10. Draft contract
This step includes creation of draft contract.
11. Review contract
The contract will be reviewed.
12. Sign contract
The contract will be signed in this step.
13. End
The process ends here.
Table 5 shows that the WO-process is initiated by filling in a request that describes the
key parameters needed for the work order creation. In case there is insufficient information, for example, some important deliverables from the customer have not been
completed, an action plan will be created for filling in the gaps. This is part of the handover sub-process. Once there is enough data available for creation of the work order,
the initial version of the solution and the work estimation can be started by the solution
team of the case company. As the end result of this phase, a draft project plan including its preliminary schedule, resource allocation, scope and other relevant project related information including the draft work order will be provided for the customer’s review
by the case company. The customer review can result either in iteration of the draft
solution and estimates, in case there are any open issues; or progress the process to
the next step, which is the review of the contract. Once the contract is successfully reviewed the process can proceed to the sign of the contract and the end of the process.
18
It is noteworthy that the progress of the process described above describes the successful end result of the WO-process. It does not mean that the end result is practically
always positive for the case company and the process progresses in a straight line. In
practice, the WO-process is typically hectic and fast-paced and thus requires continuous attention and contribution from all stakeholders. In this kind of environment, the
process efficiency and effectiveness are highly needed in order to reach a satisfactory
outcome for all parties.
3.2.2
Project Delivery Process
The purpose of the Project Delivery process is to deliver the agreed results, which may,
for example, mean delivery of a service, product or some other end result, to the customer according to the project plan. Since project in its nature is temporary (Manning
2008), so the project team, other groups and stakeholders are assigned to a project to
accomplish particular tasks under time constraints.
Typical functions in IT-projects are requirements analysis, technical design and implementation, unit testing, integration and system testing and deployment. The prerequisite for starting a new project and Project Delivery process is the customer’s acceptance of the work order. Figure 6 below shows the Project Delivery process followed in the case company.
19
Figure 6. Project delivery process in the case company.
As seen from Figure 6 above, the case company utilizes two different methodologies,
namely the waterfall and agile type of methodologies, which can also be combined for
executing a project. Regardless of which methodology is selected, both types of projects has same decision points (DP) and gate reviews (G). The prerequisite for starting
a new project and Project Delivery process is the customer’s acceptance of the Work
Order.
Since any project is temporary by its nature (Manning 2008), so the project team, other
groups and stakeholders are assigned to a project to accomplish particular tasks under
time constraints. Typical functions in IT-projects are requirements analysis, technical
design and implementation, unit testing, integration and system testing and deployment. In Figure 6, there are 4 decision points and 6 gates review in the process. The
key stages include a) analysis, b) design, c) code & unit testing, d) integration & system
testing, e) acceptance testing and f) implementation & deployment stages. The steps of
the both types of the projects are described in more detail level in Table 6 below.
20
Table 6. Description of the project delivery process steps.
Process step:
Decision points
Agile Lifecycle
Waterfall lifecycle
Both Project Types
Project
type
Description
DP1
Customer has accepted Work Order and made the decision to
execute the proposed project. The project will be started usually
by mutual Project Kick-Off meeting.
DP2
Optional decision point; for example in case when the project is
started but the scope requires clarification at some point of the
project, it can be mutually agreed that the scope will be reviewed
at P2+ and if necessary, align the costs and schedule accordingly.
DP3
Decision point for technical deployment
DP4
Decision point for business launch, usually requires customer
involvement and the decision point reflects mostly action taken in
customer organization
Gates (G1 – G6)
Gates are part of quality assurance of projects and intention of
each gate is to confirm that a project has delivered all required
deliverables in a particular moment in the process.
Analysis
The functional specification based on business requirements will
be produced within Analysis phase.
Design
Design phase means a technical design based on functional
specifications. During this phase architecture of the system and
the application structure will be designed. This phase has close
tie with the next phase (Code and unit testing) and sometimes
they both are practically in the same phase.
Code and
testing
unit
This phase includes practical coding of the system, based on the
knowledge gained from prior phases, and unit testing of the end
results.
Integration
and
system testing
Once the software is developed and unit tested, professional
testers will test it in two separate environments; integration test
environment and system test environment.
Acceptance testing
Once the software has passed the previous testing successfully, it
can be delivered for the acceptance testing done by the customer.
Implementation
and deployment
As a result of successful acceptance testing by the customer, the
software can be transferred to production environment. This calls
for preparation and planning, and the final deliverable from this
phase is functional software in the production environment.
Sprint planning
One sprint lasts typically several weeks, for example 4 weeks.
Content, what will be achieved to be done in a sprint will be
planned in sprint planning phase.
Sprint execution
During sprint execution phase tasks planned in sprint planning
phase will be executed.
Integration
and
system testing
Same as previously described with waterfall lifecycle step.
Acceptance test-
Same as previously described with waterfall lifecycle step.
21
ing
Implementation
and deployment
Same as previously described with waterfall lifecycle step.
Table 6 shows that phases in the waterfall lifecycle are described to run sequentially;
however, in practice two or more phases may be running in parallel. For example, in
the case company the analysis phase can be partly unfinished when technical design
and test planning are already in progress.
In Agile Lifecycle, as described in Table 6 above, the steps are repeated several times
during a project, and one cycle of steps is called a sprint. The purpose of this approach
is to develop the desired end result incrementally, which means that the part of the
developed entity is possible to demonstrate to the customer at the end of each completed sprint. Demonstrating an unfinished product during the project increases transparency and enable possibility to include changes into the project scope rapidly.
Both project types includes Decision Points, which are required to complete in order to
continue the process. Quality Gates are also involved in both project types and meaning of Quality Gates is to confirm that a project has delivered all required deliverables in
a particular moment in the process.
As revealed by the results of the current state analysis, both processes the Work Order
and the Project Delivery processes, have their challenges. They are discussed in more
detail below.
3.3
Challenges in the Current Work Order and Project Delivery Processes
The current state of the Work Order and Project Delivery processes contain some challenges and examination of these challenges done by interviewing participants from
both onsite and offshore, revealed the following results. The challenges in the both
processes were summarized into 50 identified issues, categorized into 8 different areas. These areas are related either to the Work Order or the Project Delivery process, or
in some cases both of them. The findings were restricted to only the first priority findings indicated by the interviewees as their key areas of concern. The overview of the
distribution of the results is presented in Table 7 below.
22
Table 7. Distribution of findings from interviews.
Project delivery
process
8
Both
processes
3
Total
Practices
Work order
Process
3
14
Priority
1 level
5
Knowledge Transfer
1
8
1
10
1
Proposal Planning
7
-
-
7
4
Tools
-
5
1
6
3
Culture
-
3
2
5
1
Language
-
2
1
3
1
Team Building
-
1
2
3
2
Project Planning
-
2
-
2
1
Total
11
29
10
50
-
Development area
As Table 7 shows, most of the findings are related to the Project Delivery process (totally 29 findings), or the practices development area (14 findings). However, it must be
noticed that the number of findings per area or process does not reveal the importance
of observations. Therefore, these findings were also evaluated and prioritized with the
interviewed people in Data 1 collection phase. As a result from the evaluation and prioritization, the most significant findings were marked as the high priority findings and
categorized into groups for further analysis (marked in the Table 7 above on the scale
from 3, the lowest priority, to 1, the highest priority).
Based on the evaluation and prioritizing done together with the interviewed people, the
most significant findings in the Work Order process are related to Proposal planning
area. Other and only area that received also prioritizations was practices area. In the
Project Delivery process, the Practices and Tools areas received the highest prioritizations, whereas the other areas received much less attention. The key findings are discussed in more detail in the next sections.
3.3.1
Key Problems of the Work Order Process
The Work Order process was summarized into six Priority level 1 findings, with most of
the findings related either to the proposal planning or practices areas. These recognized problems related to the Work Order process are presented in Table 8 below.
23
Table 8. Most significant observations in the work order process.
Problem
1.
2.
3.
4.
5.
6.
Area
Description of the problem
Practices:
Time Constraints
Practices:
Cost Estimation
The Work Order process overall is too heavy,
especially in big projects the fixed duration of
the WO process is not enough to complete WO
No common practice and tool for cost estimations. Onsite and offshore use different Excel
templates which are not comparable; this generates lot of unnecessary work during WOprocess
Business requirements from the customer are
often in too high level
Proposal planning: Initial
Documents
Proposal planning: Resource planning
Proposal planning: Initial
Documents
Proposal planning:
Cost Estimation
Business
impact
Offshore party has been taken into process
usually too late within the process
Customer documentation is translated usually
too late in the process
Lot of different system-specific Excel templates
for cost estimation in onsite. Lot of system specific templates for cost estimation, which are not
uniform with offshore
Table 8 above also contains the evaluation of the business impact made by the interviews on the scale of green, yellow and red (meaning green – limited, yellow – intermediate, red – significant).
As seen from the Table 8 above, the problems that has the most significant impact on
the business relate to both groups, the practices and proposal planning, but mostly to
the proposal planning stage. Among them, the cost estimation problem was considered
as especially important and also critical to business by the interviewees. One interviewee commented on that problem as follows:
We spend lot of time on cost estimation in both onsite and offshore, however our
way to do estimates differs from each other enormously as both sides do estimates into different structure, using different units and overall estimate things
from different angel. As a result we spend lot of valuable time during the process
to just unify those estimates. If we had streamlined estimation practices and tools
from the beginning, we could achieve better results in less time when doing proposal planning.
(Person-1).
That statement illustrates the significance of cost estimations discrepancies. It also
points to a possible way to improve it by creating or developing a common method for
cost estimations. Presently, the current state lacks such synchronized practices and
24
the problem affects many stakeholders in the WO-process. If discussed deeper, the
interviewees pointed that this problems relates to other challenges, including: first, the
collaboration between onsite and offshore is not at the level it could be as the problem
causes interference to communication and calculation of the business case of the project during the WO-process. Second, the management may not receive constantly upto-date information about the current state of the business case within the WO-process.
Lack of such information is critical, because working during the WO-process is intense
and real-time information is necessary for support of decision to the management.
Third, the long term risks increase if estimations include some uncertainty or possibility
of an error in calculations due to differences in the methodologies between the onsite
and offshore. These risks may become visible especially to the customer which then
becomes a question of reputation, reliability and credibility of the case company in the
eyes of the customer. As a result, cost estimation was mentioned by many interviewees as a key challenge.
Another problem initial documents in both practices and proposal planning area are not
detailed enough, have not only significant impact on business but also on quality of the
WO-process. In Data 1 collection phase, the interviewees recognized the problem as a
wide issue in the case company, as one interviewee expressed it:
Very often we got business requirements from the customer that are in too high
level causing lack of understanding of the scope of the project. Sometimes requirements are not clear enough for the customer itself.
(Person-7).
This opinion was often repeated by the interviewees and thus makes an important finding. Possible misunderstanding of the scope of the project in an early phase leaves the
door open for interpretation in the later phases. In case some important phase or task
is not mutually and equally understood with the customer, it can end up in bringing
down benefit for the customer and the loss for the case company. Summing up, both,
the customer and the case company, are under the influence of this particular problem.
Despite the fact that expression above presents mostly the opinions from onsite, some
offshore people share this view.
In addition to that, the problems described above have impact on the WO-process
overall but in a wider form they reach to impact on the Project Delivery process as well.
At worst, occurrence of most of the problems simultaneously might result the WO-
25
process with bad quality of the end results and thus produce unhealthy premises for
the forthcoming project.
3.3.2
Key Problems of Project Delivery Process
The project delivery process includes 11 different key findings that are evaluated and
recognized as Priority level 1. They are divided into several different sub-areas such as
culture, knowledge transfer, language, project planning, practices, team building and
tools. Table 9 below shows the challenges in the Project Delivery process and the
evaluation of the business impact made by the interviews (meaning green – limited,
yellow – intermediate, red – significant).
Table 9. Most significant findings in the Project Delivery process.
Number
Area
Description of the problem
1.
Culture
Offshore people do not indicate directly if they
have not understood something well enough,
instead they try to find reply to unclear issues by
roundabout.
2.
Knowledge
Transfer
No common document repository for recording
project related changes per system.
3.
Language:
Communication
Business and application related vocabulary is
missing and people use often different terms for a
same thing, need is for companywide vocabulary.
4.
Project Planning:
Resourcing
No dedicated offshore support person in onsite in
the project.
5.
Practices:
Reporting
Onsite and offshore have different templates for
reporting.
6.
Practices:
Reporting
The project accounting tool for Portfolio management reporting is inadequate
7.
Practices:
SW-Development
Regular code reviews are missing
8.
Team building:
Resourcing
Team building (onsite/offshore) takes lot of time
during the project.
9.
Tools:
Communication
Poor audio line to offshore and difficult current
tools like LiveMeeting, Lync is recommended by
interviewees.
10.
Tools: SWDevelopment
Version handling tool is missing in some particular
older applications.
11.
Tools: SWDevelopment
Configuration management tool is missing in particular older applications
Business
impact
26
As seen from Table 9 above, the reporting and communication problems (areas 5,6
and 3,9) make the most important findings in business impact viewpoint. The reporting
problems are recognized widely among project management professionals and considered to having large impact on business. One evidence of this is a statement of one
interviewed project manager:
As we already know what to report to the management and customer and we have formal templates for reporting this end, we should expand current practices to cover offshore reporting practices. By doing this we can confirm that reported data does not
change on the interface between offshore and onsite and we can also reduce unnecessary work done with incompatible reports.
(Person-1).
This statement shows that the reporting practices seems to be in order in the onsite
location, but the current reporting practices in onsite are not expanded to cover offshore. Offshore have their own reporting templates and practices, which are not uniform with offshore templates and practices, and very often reporting practices are
agreed case by case between onsite and offshore, so there are deviations in reporting
between the projects. This particular problem not only causes additional work but also
increases risk of error in reporting. Possible error in reporting has multi-dimensional
effects. For example, in hypothetical situation where monthly report includes some serious errors due to deviations in reporting between offshore and onsite, the management get wrong vision of the progress of the project. Moreover, the customer may inadvertently be reported false economic data. If the error is not immediately detected, it
can accumulate and therefore cause problems in the medium term.
The communication problem has identified as an important topic among the interviewees and especially in business analysis and software development point of view. The
problem comes up often during the analysis, design and code & unit testing project
phases. Typically people in both offshore and onsite discuss about the business related
matters with different terminologies. Difference in terminologies used in business related terms causes misunderstanding and additional work for clarification of issues. Extension of the communication problem is not only limited to the collaboration between
offshore and onsite, but it also applies to onsite activities more widely. Problem in onsite is that one and common English vocabulary for business terminology does not exist, but few vocabularies are at the place and used by different units in the case company. This problem occurs especially when cooperating across the business unit
boundaries and also in cooperation between the offshore and onsite.
27
3.4
Summary of Current State Analysis (Two Processes) and Focus Areas
Sections 3.3.1 and 3.3.2 showed the current and the most significant findings in both
the Work Order and Project Delivery processes from the business impact viewpoint. If
summarized, the findings from the current state of both processes in the case company
point to the following challenges.
First, the current state of the Work Order process includes findings that are mainly focused in two main areas in the WO-process. Figure 7 below shows identified challenging areas in the current state of the Work Order process marked with red oval figure.
Figure 7. The current challenge areas in the work order process.
As Figure 7 shows, two steps in the WO-process are recognized to contain the most of
the current challenges. The work estimation related challenges, which were discussed
in more detail in Section 3.3.1, make the most significant current challenges in the draft
initial version of solution and work estimate step of the WO-process. The challenges
identified in this step were recognized the most significant findings as they were prioritized in level 1 among the interviewees and also having big impact on the business.
The challenges in this area are related to cost estimation practices and tools used for
the estimation. Accurate cost estimations brings reliability and predictability to the pro-
28
ject delivery and contributes to risk management, therefore cost estimations overall
plays important role in terms of business.
Another identified challenge in the WO-process is the handover process step, including
also priority level 1 findings with big impact on the business. The handover process is
prerequisite for the draft initial version of solution and work estimate step. Very often
challenges in handover process are related to the level of preliminary specifications of
the service for which a proposal is requested. The problem in this area has many aspects. First, unclear or too high level specifications of the service may cause several
iteration rounds, which binds time from both the customer and the case company. Second, this problem includes realistic risk that part of the unclear specifications will roll to
the upcoming project and the risk realises at some point of the project.
Other particular steps of the WO-process were not identified as a challenging or in
need of improvement during the Data 1 collection. For example, the lead time of the
WO-process was experienced as too short in big projects, which is not always the case
in small or medium size projects. Summing up, the WO-process seems to be in order
for the most part, but the starting steps in the process requires some improvement.
Such improvements might bring business benefits for the company and enable stability
to the project delivery.
Second, the Project Delivery process contains many problems that do not apply to only
one part of the process but many and, in some cases, the challenges throughout the
process. Many of the Project Delivery challenges also reflect to a more general context
of the project work. For example, different cultural or language related problems were
recognized among the people, from both onsite and offshore. Since these types of
problems are difficult to assign to any particular part of the Project Delivery process,
they are not marked in Figure 8 below which shows only the key and recognizable
challenges of the Project Delivery process. Thus, Figure 8 shows the most problematic
areas of the project delivery process marked with red oval below.
29
Figure 8. Identified problematic parts of the project delivery process.
As Figure 8 shows the current challenges of the Project Delivery process are related to
the beginning and middle stages of the process as the end part of the process have
practically no any identified problems. The problems described above in Figure 8,
which are not directly related to the process and hence not marked in the following process chart, are reported to the management of the case company among other challenges and their further processing will be decided case-by-case by the management.
Although the challenges revealed in the Project Delivery process seem to be many, in
many respects, they are relatively easy to solve. For example, the common reporting
practices that would cover all projects between onsite and offshore could be relatively
easy to implement. The existing positive experiences from reporting in customer interface could provide a basis for extending the reporting practices also to offshore. The
common and shared reporting practices through the organization to the customer create the conditions for dealing with accurate information and reduces unnecessary work.
Therefore, it was this area in particular that was decided to be taken as a focus of im-
30
provement efforts in this study. More details of the challenges of reporting practices are
discussed below.
Summing up, the both processes are interrelated and depended on each other. The
concept of the two processes, where first, the WO-process is dedicated to response to
the request for proposal from the customer and, second, it results in a successful completion of the WO-process, seems to be functional but includes some weak points. Current state of the Project Delivery Business Unit can be regarded as functional and relatively straightforward in general level. Nonetheless some business benefits can be
gained by doing some improvements to the both processes.
Most significant problems in the Work Order process relate either to proposal planning
or practices areas. In the proposal planning area, the business requirements from the
customer were considered to be on too high a level and the current system specific
cost estimation templates were considered to be not uniform with the offshore. The
Project Delivery Process also includes a number of challenges which in most cases
have either middle or low business impact. Notwithstanding this fact, the reporting
practices were considered to have a visible and important footprint throughout the organization to the customer. Therefore, the challenges in the reporting practices were
selected as the most significant findings and the focus area in the Project Delivery Process. The next section discusses the reporting in existing knowledge point of view.
3.5
Examination of the Challenges in the Current Reporting Practices
In order to specify the challenges of the current reporting practices in more detail, the
results of the current state analysis were further analyzed, focusing on the reporting
practices in particular.
3.5.1
Map and Description of the Current Reporting in the Project Delivery
The current reporting in the case company consists of report templates, reporting cycles and different roles involved in the reporting process. The current map of reporting
is shown Figure 9 below.
31
Figure 9. The current reporting map in the case company.
Figure 9 shows four reporting lines in the case company Project delivery process. The
green circles reflect the reporting frequency, for example, in Line 1, the Portfolio management, they show the report which happens every four week. Line 2, Steering group,
also receives a report every four weeks, but their reporting cycle is often related to the
progress in a project in general and various project phases. The customer (Line 3) receives their weekly report every week and the offshore team (Line 4) is expected to
report their progress also on a weekly basis. Reporting responsibilities are divided so
that the offshore project manager reports on the project progress to the onsite project
manager. The onsite project manager is responsible for reporting to the customer,
steering group and portfolio management group.
3.5.2
Identification of Improvement Needs in the Current Reporting
The findings related to the reporting practices were collected from the interviews, workshops with interviewees and discussions with other than interviewed people in the case
company. A deeper analysis of the findings related to reporting included the following
identified issues: a) offshore is lacking a proper weekly report, b) offshore is lacking the
general process and awareness of reporting, c) reporting is not consistent through the
business line, d) the current finance forecast report is missing some information, and e)
the project accounting tool for HC reporting is inadequate. Examples below demon-
32
strate the content and significance of the identified issues visible in the current reporting practices.
First, offshore weekly reporting is currently agreed on a project by project basis, meaning that there is no common and formal Template for reporting from offshore to onsite.
As the reporting practices vary across the projects, accuracy of the progress data varies too, so that some data is obviously lacking in some of the offshore reports. This
problem is visible especially when it comes to reporting of: a) the issues that offshore
has faced, b) the resource assignments, and c) the financial information between baseline and forecast. This problems were widely discussed in Data 1 and recognized as an
important issue.
Second, the current project accounting tool for Health Check (HC) reporting is inadequate since it is missing vital information. The Portfolio management monitors the performance of the project portfolio and each individual project through the HC Report. It is
a project manager’s responsibility to fill in the financial data into the HC Report monthly. Presently, the project manager uses several sources for collecting the necessary
data for the HC report, including the project accounting tool. Figure 10 below shows a
snapshot of the summary tab in the project accounting tool.
Figure 10. Summary Tab of the Project Accounting Tool.
Figure 10 show the summary tab of the tool and filled in with fictional data. In addition
to that big amount of data, the tool includes separate tabs for forecast estimation and
history information, also summarized in the summary tab. As seen from Figure 10, the
tool provides common financial figures such as revenue, costs and margin for different
moment of time as initial project estimate, actual to date, remaining and updated project estimate. The point is that this information can be partially used to fill in data in the
33
HC Report. Two snapshots of the HC report are presented in Appendix 9, which include the snapshot of the estimates and financial tabs of the HC tool. This view also
reveals what information can used directly from the tool (green squares in the snapshot). As Appendix 9 shows, some information can be gained from the tool in the financial tab; however, other tabs requires other sources or additional calculating in order to
be filled in. Thus, among the current problems with the project accounting tool the following challenges can be named: a) data fields in both the tool and the HC Report
show a mismatch in some places, b) the tool does not provide all required data for the
HC Report, c) the current data from the tool is ambiguous in some places, and d) the
tool does not provide any help texts giving guidelines or examples how to fill in the tables.
Third, the financial forecast report is currently missing some important data. Figure 11
below is a snapshot of the financial report revealing the project resources tab.
Figure 11. The financial forecast report.
As seen from Figure 11, the financial forecast report includes several tabs with different
kind of project information. The current challenges with the report include: a) resourcing
cannot be done by using percentages (green squares in Figure 11), and b) revenue
information is not available in the report.
34
3.5.3
Summary of Key Findings from the Current Reporting Practices in Project Delivery
If summarized, the current state analysis related to the challenges in reporting practices clearly points to the three areas related to the project reporting practices in the Project Delivery process, which need improvement. They are shown in Table 10 below.
Table 10. Project reporting challenges in the case company.
Problems focused
Description of identified gaps /
into one area
What? How? By what meant to report?
1.
No common and
formal report for
reporting from
offshore to onsite
2.
The project accounting tool for
Portfolio management reporting
is inadequate
3.
Finance Forecast
report is missing
some practical
financial information
There is a need for having progress report from offshore in a form
that current weekly report does not support. Practices and content
of offshore reporting varies project by project.
List the missing details here includes, for example:
- The current issues with the project
- Resource assignments
- Project data compared between baseline and forecast
Excel tool is non-uniform with Portfolio Management HC report
data. It requires additional information and conformity in accordance with HC.
List the missing details includes, for example:
- Data gathered from other source than the tool for HC,
should be included in the tool
- Field names should be matched between the tool and HC
report
- Help texts to provide guidance filling in and using the tool
Lacking of some financial information causes extra work. Adding
some recognized information in tool might save worktime and
increase accuracy of the data.
List the missing details includes, for example:
- Resource allocation should be done by using percentages
- Revenue information should be visible
The findings from Table 10 suggest that the project reporting challenges are related to
three areas: a) the offshore team is lacking the reporting Temple for the offshore progress reporting, b) the project accounting tool is waiting for improvements, and c) the
lack of data in the finance forecast report. These challenges point to the more general
questions related to reporting practices, namely what, how and by what means the effective reporting practices should be done and how to improve them.
The current state analysis of the existing reporting practices in the Project Delivery process was summarized out of totally 53 findings revealed from both the WO-process or
PD processes. Figure 12 below shows the logic of categorization of the findings to the
focus areas and also points to the three main questions which need to be addressed to
explore and find an effective solution to the identified challenges.
35
Figure 12. Focus areas and main questions from the current state analysis.
As seen from Figure 12, the focus area among the development areas was chosen to
be the current reporting practices. The identified challenges included five different problems identified in Data 1. The main challenges were further categorized into three logical questions related to the more general problems of reporting for further examination
in the literature. Due to significance of reporting practices to the whole Project Delivery
process, this areas has been chosen to be the main focus area of this study. The next
section discusses the reporting improvements from the best practice point of view.
36
4
Existing Knowledge in IT Project Reporting
This section discusses the existing knowledge and best practice in the project reporting
field. The section starts with overview of project reporting following three main topics as
project control, project monitoring and reporting and reporting practices, reflecting the
outcome from CSA. Finally, it introduces the conceptual framework of this study.
4.1
Overview of Project Reporting as Part of Project Management
Project management means project based operations and delivery. In order to meet
the obligations of the project, as well as to keep all stakeholders informed about the
project related topics, a project requires methods to help managing the project related
matters. Chemuturi (2013) describes project management as the application of
knowledge, skills, tools, techniques and resources to the project activities to meet or
exceed stakeholder needs and expectations. It is the discipline of planning, organizing,
staffing, coordinating, and controlling project activities to ensure that project deliverables conform to specifications, and are on time and within budget (Chemuturi 2013:
16). In addition to that Patel (2008) writes that Project management is composed of
several different types of activities as planning the work or objectives, organizing the
work, risk management, resource management, controlling project execution, quality
management and tracking and reporting progress among others (Patel 2008: 7). Thus,
it can be said that the project management provides a framework for the project delivery offering necessary tools and practices within.
According to Patel (2008), a project is a temporary and one-time endeavor undertaken
to create a unique product or service that brings about beneficial change or added value. This property of being a temporary and a one-time undertaking contrasts with processes, or operations, which are permanent or semi-permanent ongoing functional
work to create the same product or service over and over again. Moreover, a project is
a carefully selected set of activities chosen to use resources (time, money, people,
materials, energy, space, provisions, communication, quality, risk etc.) to meet the predefined objectives (Patel 2008: 2).
In information technology especially, the typical way to deliver services or products is a
project delivery model. Though the project management is a topic, which is based on
solid empirical knowledge and practices that are refined in many companies, the pro-
37
ject delivery is still challenging. One proof of the project challenges is the claim (Cane
2007) that technology projects fail regularly. He explains failures by schedule delay,
budget overrun, non-functional technology and deliverables that does not meet the
customer expectations (Cane 2007:1). That explanation shows how challenging project
delivery can be. It also indicates that each project is a unique entity, though they have
similarities, and even though same project management practices had applied to multiple projects, the end results of the projects would differ from each other significantly.
One part of the project management and partial prerequisites for the communication in
the projects is project reporting. Systematic project reporting process and practices can
provide up to date and timely information to the stakeholders. Providing information in a
form which satisfies the stakeholders is only one part of the reporting as one aspect is
to gather information from several sources and refine and analyze that information into
desired form. The next topic discusses project controlling that makes it possible to
gather required information for reporting.
4.2
Project Control in IT Projects
Since the main aspects of the project management and pointed out that one part of the
project management is controlling the project execution this activity can be separated
into a specific area from other reporting practices. When other project reporting practices includes for example reporting tools, templates or stakeholders, controlling the
project execution provides input, or in other words, raw data, for further data handling
and processing. Hence project controlling establish a data source for reporting.
Business practice suggests that the project control typically involves the five activities.
First, the planning activities based on approved organizational norms or baselines.
Second, measuring progress (schedule, quality, productivity, and cost) of the project
periodically with the time intervals specified depending on the nature and aims of the
project. Third, comparing the actual progress with the planned progress and finding the
variances, which is done with the purpose to evaluate the project progress. Fourth,
taking corrective actions for variances. If, for example, the schedule in not on track with
the baseline and thus causing variance to planned schedule, project manager is responsible to plan and execute corrective actions in order to get project back on planned
schedule. Fifth, taking preventive actions to keep the actual progress aligned with
planned progress in the future. For a project to be completed on time and within the
38
approved budget, close control of the project execution must be exercised (Chemuturi
2013: 147). Thus, the project control provides the skills to carry out the project according to the project plan. In addition to this, appropriate project control creates the conditions for collecting and analyzing appropriate information from the project and moreover to refine that information into form of the project report.
The project progress measuring includes four main parameters that are a) schedule, b)
cost, c) quality and d) productivity. Controlling of these parameters requires several
measurements, analyzing and performing numerous activities to keep the project under
control. The following sub-sections discuss these parameters in more detail.
4.2.1
Schedule Control
Project schedule, according to Hulet (2006) helps to predict the completion and milestone dates of the project. It is also used to manage daily activities and resources and
to record status (Hulet 2006:47). For that reason the schedule constitutes a body for
the project and thus plays significant role in the project management. Chemuturi emphasizes the significance of the schedule control by claiming that control of the project
schedule is the most important aspect of IT project execution. Further on he reveals
that delaying the schedule would have the consequences of delaying the planned business operations. That means we would not only have to bear the cost of project delay,
but also lost revenue that would have accrued from the planned business operations
using the IT infrastructure set up by the project (Chemuturi 2013: 148). Regardless of
the outcome that the delayed schedule results, Hulet (2009) points out that main issue
in the schedule risk analysis is uncertainty in activity duration (Hulet 2009: 72).
IT project schedule typically includes activities that are to be performed either sequentially, meaning they performed one after the other, or in parallel, when they are performed at the same time, concurrently. Critical activities are those that cannot be delayed at all. In other words, any delay in completion of a critical activity would delay the
entire project by the same amount. Chemuturi (2006) summarizes the project schedule
control by a) all critical activities are closely monitored and all required resources are
provided on time b) all critical activities schedule and c) the noncritical activities are
completed before their latest completion dates (Chemuturi 2006: 150). Hulet (2009)
supplements that idea by stating that showing a project’s schedule problems clearly
and realistically in the schedule early in the project offers the possibility of fixing those
39
problems. If the scheduler is forced to use late-date constraints after the schedule
baseline has been set, they may communicate to management that the project is late
by focusing on the paths with the most negative float. Showing negative-float paths
indicates clearly that the project is not finishing on time while technically adhering to a
date that has proved to be unrealistic (Hulett 2009: 53).
4.2.2
Cost Control
Project cost includes all cost incurred during execution of the project and typical project
costs are for example staff costs, material costs, cost of capital and travel costs. Project manager is responsible for following project costs and for example stuff costs are
typically followed through hour booking system. Nature of especially waterfall type of
projects includes advanced planning of the schedule, resources, deliverables and cost,
among others. The project costs could be either fixed or variable as a type. In literature
Chemuturi (2013), the fixed costs are defined as costs that are not tied specifically to
project execution or any deliverable, but instead to the duration of project. Example of
the typical fixed costs are salaries, office expenses or interest on financial expenses.
Variable costs, in turn, are those expenses that are tied to payments made for the execution of the project. These include payment for materials procured, contractor payments against completed work, and expenses on utilities such as power, communications, and so on Chemuturi (2013: 151-152).
Chemuturi (2013) suggest few ways to control and contain or save in fixed costs of a
project. Firstly, paying attention to close monitoring of the schedule in order to complete the project on schedule, or if possible even sooner than planned. He also suggests to set these cost low in the first place, if possible, which means careful project
planning. Second, the project resource allocation should be consist. In a case where a
project is fully allocated from the beginning, fixed costs will be high, therefore only few
essential staff should be allocated in the beginning and allocation should be ramp up
only when additional resources become essential. As important as ramp up of allocation during the project is de-allocation staff immediately upon completion of their assignment on a project, which saves the fixed cost component of the project. Third, the
cost of capital incurs some expenses. To minimize the cost of capital employed is to
carefully plan ahead and meticulously schedule the requirement of funds. When these
dates are accurately predicted, funds are not unnecessarily locked up waiting to be
spent. Accurate projection of the funds requirement and ensuring the project adheres
40
to the schedule during execution would reduce wasteful expenditure on the cost of capital employed (Chemuturi 2013: 153).
There are many ways in an IT project to leading escalated project costs. According to
Chemuturi (2013) the major expenses of fixed costs stem from overhead, salaries, and
office expenses, therefore carefully project planning and scheduling the ramp-up and
ramp-down of resources in order to contain fixed costs are essential in cost control
(Chemuturi 2013: 152). The cost control starts partially from the project planning
phase, where some of the decisions have done have significant impact on the project
in cost wise. The cost control requires deep understanding of the project scope, ability
to see the project progress in longer range and ability to response to changes in the
planned costs.
4.2.3
Quality Control
ISO (ISO 9000, 2005) defines quality as a degree to which a set of inherent characteristics fulfils requirements (ISO 9000, 2005: 3.1). According to Chemuturi (2013) ensuring quality begins in the planning stage of a project wherein standards are selected to
which the project must adhere to. Selecting and communicating the appropriate standards to all concerned with project execution is the first step. Testing of all project outcomes is important and for testing each piece of equipment or software, a test plan
need to be planned, test cases to be defined, and finally executed them. Acceptance
testing of the software is conducted when the development team offers it, to ensure all
requirements are met and it is working as desired. One important aspect of quality control to note is that the authority to hold up work even to the extent of affecting the
schedule exists. Sometimes it may genuinely be necessary to delay the work even at
the risk of affecting the schedule (Chemuturi 2013: 155). Quality assurance requires
testing professionals to plan and execute testing and necessary system to track findings from testing and their status. Part of the quality control is to prevent delivery of an
outcome that is under agreed standards, even though it would require bending the project schedule.
41
4.2.4
Productive Control
Chemuturi (2013) defines productivity as the amount of effort expressed in personhours/minutes for accomplishing a unit of work by an averagely skilled person putting in
an average level of effort. Example of using productivity is while estimating the human
effort required in accomplishing the work, if productivity is poor, it takes more effort per
unit of work than estimated. The ramifications of poor productivity are an increase in
project effort and related costs and schedule slippages. Therefore, it is essential to
ensure that the allocated number of resources equals the estimated number when
normalizing the skill levels of allocated team members to the average level of skill. If
the number is not equal, there will be a variance between the estimated effort and actual effort, leading to possible slippage of the schedule and a cost variance (Chemuturi
2013: 156). The allocation of resources and focusing competence rightly, has possibilities to impact on productivity of a project.
4.3
Project Monitoring and Reporting as a Continuous Process
According to Roberts (2007) monitoring is the observation and supervision those in the
management team must do to know the condition of their projects. Without reporting it
is not easy to monitor a project and without appropriate level of monitoring a project
risk level may increase. Each level in the management hierarchy need information in a
form and at a frequency that allows the exercising of control without encroaching on the
responsibilities of other levels. It is also critical that such reports show the extent to
which the project is likely to meet its completion expectations, giving any necessary reforecast of the expectations originally set out in the project plan. (Roberts 2007: 170).
As the project organization contains different levels in the hierarchy such as project
team, steering group or portfolio management team, each of them have different needs
and requirements towards project reporting. This means that each tier needs a report
or reports that are designed for that particular level context. The next sections discuss
the different management tiers and recommends suitable reporting practices based on
existing knowledge in literature.
Summing up, monitoring and reporting progress, being a continuous activity of project
management, has a significant role in the project management because reporting gives
visibility of a project status to the project stakeholders.
42
4.3.1
Project Portfolio Management Team
Companies, especially some IT service providers, typically have/ may have several
projects ongoing simultaneously. In such a situation, the management of a company
might want to see the overview of all projects at once instead of listening to individual
reports from teams, say, one by one; especially if the same teams are responsible for
more than one project. This model is illustrated in the idea of the project Portfolio management. Moustafaev (20010) defines the project portfolio management as a methodology for analyzing, selecting, and collectively managing a group of the current or proposed projects based on numerous key characteristics while honoring constraints imposed by management or external real-world factors (Moustafaev 2010: 215). According to Roberts (2007) the portfolio management team is ultimately responsible for the
state of the portfolio, thus the team must meet regular basis to evaluate the health of
the portfolio. A typical cycle for portfolio management team meetings, according to
Roberts (2007), is once in a month, but readiness to meet at short notice in case of
exceptional matters should be in place. (Roberts 2007: 171).
The portfolio management is known to include three key requirements that each project
or portfolio typically meets according to Moustafaev (2010). First, each project as well
as the portfolio of projects should maximize the value for the company. As the value
might have different meaning depending on the company, in this context it refers to
economic measures such as return on investment, net present value, competitive advantage, expected sales and so on. Second, the candidate project should preserve the
desired balance in the portfolio mix meaning that project portfolio should avoid certain
situations. For example, the portfolio should avoid situation where it includes too many
small and visionary projects or too many short-term and not enough long-term strategic
projects. Moreover, successfully balanced portfolio does not include projects with a
disproportionate amount of resources devoted to a few business areas while other important areas are in need or projects with a poor risk management. Third, the final portfolio of projects should be strategically aligned and should reflect the business’s strategy. The fit to the strategic goals requirement makes certain that company finances and
other resources are not wasted on ventures outside of the organization’s sphere of
strategic interests (Moustafaev 2010: 216). That is to say, changes in a company’s
strategy is shown with a delay in the project portfolio.
43
Management and monitoring of many ongoing projects requires practices that differentiate from one project monitoring and management to another. Portfolio management
team requires formal report in the portfolio team meeting for the monitoring health of
the portfolio.
4.3.2
Steering Group
In typical IT service delivery project, steering group consists of people with mandate to
make decision from the customer and IT service provider. Roberts (2007) explains that
steering group directs an individual project and is responsible for making sure that the
expectations set out in the business case for the project are met. It will commission the
project plan from the project manager and, assuming it is agreed, will authorize the
start of the project as well as it also authorizes any significant changes to the plan that
are outside the project manager’s authority. As the project manager will have only limited authority, the project steering group adjudicates on any conflicts within the project
and resolves problems between the project and third parties, internal departments or
other projects. Steering group has been given its authority by the portfolio management
team once the financial and other resources have been allocated (Roberts 2007: 45).
Typically steering group meetings are held regularly, often monthly basis, where project
manager reports the status of the project.
Ciampa (1992) describes five elements that makes the successful steering group and
they are a) the steering group should be made up of senior managers b) the steering
group must have public license to act from the leader and have constant, visible support of the top team c) while steering group membership is an ad hoc responsibility, the
time and effort that must be devoted to it is substantial and should be reflected in the
organization's normal performance appraisal system d) the role of the steering group
must be clearly defined by senior management before it begins to operate e) the pace
at which the steering group gets up speed is directly related to going through a teamwork development program and the establishment of a plan for the rollout of total quality (Ciampa 1992: 1). These elements, in addition to that they make the successful
steering group, are also back to project manager.
Most members of a steering group and other stakeholders are interested to see the key
project management information of the project summarized in to a report. Roberts suggests the summary project forecast report for such a purpose (Appendix 1. Summary
44
project forecast report). The summary project forecast report provides a snapshot of
the project at a level that should be satisfactory for the steering group, but sometimes
there might be a need to know more details. The reports for more detailed reporting
purposes could be, according to Roberts, the project forecast reports. There are several project forecast reports such as the time forecast report (Appendix 2), cost forecast
report, which includes two different type of cost reports, cost by type (Appendix 3) and
cost by product (Appendix 4), project quality forecast report (Appendix 5) and benefits
forecast report (Appendix 6). The terms used in most of these reports (Appendix 1-6)
are explained in Table 11 below
Table 11. Descriptions of the details in forecast reports (Roberts 2007: 181,182).
Detail
Baseline
Actual to date
(atd).
Estimate
to
complete (etc).
Forecast
completion
(fac).
Variance
Box colours
at
Description
This is the original set of data agreed by a recognized authority which
should be used as a stable foundation against which to track variances.
There may be a baseline end date, a baseline budget and a baseline benefit, which were all agreed when the business case and project governance report were approved at the end of the initiation stage. The baseline
should not be changed, so the effect of changes can be measured reliably.
There are, however, rare circumstances when it is necessary and sensible
to amend the baseline; these will be considered later.
This is a range of measures that should increase as the project progresses. For instance, if $300 of a baseline $500 budget has been spent, the
actual to date is $300.
This is a crucial set of information in any project report because it is the
latest and most recent estimate. This figure represents the amount to
come on top of the actual to date. For instance, if the actual to date is
$300 and the baseline was $500, it does not follow that the estimate to
complete is $200. The costs may have increased since the baseline was
approved and the project forecast report must record this. If the estimate
to complete is $400, the new total is $700.
This is the sum of actual to date and estimate to complete – $700 in the
example above.
This is the difference between the baseline and the forecast at completion.
In the example above, it is –$200 (the baseline $500 less the forecast at
completion $700). When compared with the agreed escalation criteria, this
figure enables the red, amber and green alert markers to be created.
Grey boxes must be completed whenever a new project forecast report is
being produced.
Table 11 shows the most common used parameters in forecast reports. Baseline is set
in the beginning of the project, and other parameters are measured usually against it.
Project manager gathers forecasts, estimates and other relevant information usually
with help of the project team.
45
4.3.3
Project Manager
Project manager is a professional in the field of project management who has the responsibility of planning, executing, controlling, and closing any project assigned to him
or her (Moustafaev 2010: 26). Some of the responsibilities of project manager include
following and reporting schedule, cost quality and risk related matters. The example of
the knowledge areas and corresponding project manager’s responsibilities are described in Table 12 below.
Table 12. Project manager’s responsibilities (Moustafaev 2010).
Knowledge Area
Project manager’s responsibilities
Integration
Develop the project management plan and get it approved
Ensure the project executes in accordance with its approved project management plan
Ensure an overall change control process is followed
Ensure the project has a signed business requirements document
Ensure the project constraints, assumptions, and dependencies are documented and agreed upon
Ensure the project schedule is decomposed to a sufficient level of detail
that allows accurate effort estimation
Ensure the project is an accurate and defined activity sequence (network
of dependencies)
Estimate project costs
Create project budget
Track budget (capital, operating expense) and report on status
Ensure documents are properly reviewed and approved
Any testing activities are planned for and executed
Get the customer acceptance
Ensure roles and responsibilities for all project team members are clearly
understood, followed, and communicated
Ensure role assignments are filled with qualified staff
Ensure that a communications plan exists for the project
Ensure project records (i.e., project plan, project status, open issues list,
meeting agendas and recaps, etc.) are kept up to date and reported in a
timely manner
Ensure that project closure occurs when the project completes
Ensure lessons learned sessions are conducted, documented, and analyzed for ongoing process improvement
Identify and quantify risks
Develop risk mitigation strategies for each risk
Communicate risks in a timely manner
Complete periodic reviews of project risks and adjust approach strategies
where necessary
Identify, quantify, communicate, and resolve project risks
Create outsourcing plans
Request vendor responses and select a vendor
Conduct contract administration and contract closure
Scope
Time
Cost
Quality
Human
re-
sources
Communications
Risk
Procurement
As seen from Table 12, totally 9 different knowledge areas are included in project managers responsibilities. Each area includes at least two different responsibilities and they
46
are generally responsibilities are multi-dimensional. Roberts (2007) explains that one
part of the project manager’s responsibility is to confirm that project executes according
to the project plan. This includes managing and motivating the project team to deliver
on time, on budget and to the required standard of quality (Roberts, 2007: 178). The
role of project manager requires extensive knowledge and expertise in order to be responsible for the tasks.
Project team meetings
Project team meetings are held more frequently than a steering group meetings. To
ensure that all stakeholders will have accurate information when needed and in order
stay up to date, project manager is recommended to arrange project team meetings
weekly basis. A model on how to gather, process, report and act on progress data of a
project is presented in Figure 13 below (Roberts, 2007:178).
Figure 13. Project progress data managing (Roberts 2007: 178).
As seen from Figure 13 the Project Forecast Report (PFR) should be sent (to the steering group) every second Tuesday. Otherwise, the process is routine as every Friday
the project team is obligated to enter timesheets, which is base for updating plan and
project forecast reporting next Monday by project manager.
47
4.4
Reporting Practices
Management and monitoring of many ongoing projects requires practices that differentiate from a single project monitoring and management. Companies have often practices and reports that are evolved and shaped according to the company’s needs. Thus, a
report that is suitable for a particular company may not fit to their competitor due to
difference in used technology that provides raw data for the reports. Therefore, companies typically explore the existing practices and adapt them to own needs. In a typical
case, reporting practices typically include reporting templates, tools and technology
varies between the companies. Roberts (2007: 171-172) recommends to utilize the
project register report for the portfolio management report is which presented in Figure
14 below.
48
Figure 14. The project register report (Roberts 2007: 172).
Figure 14 is filled in with fictional data. The report includes information about each project in the portfolio and in this case, it contains only two projects shown in two columns.
While comparing both projects presented in Figure 14, it can be seen that the first project is in order as it has no deviation in any area (Time, Cost, Benefits, and Business
49
case). The second project instead has deviations in both time and cost areas that will
breach escalation conditions. More details of the same projects are given in Table 13
below.
Stakeholders
Background
Table 13. The project register report details (Robert 2007).
Detail
Project
ID
Last assessment
date
Assessor
Project start date
Sponsor
Customer representative(s)
Developer representative(s)
Project manager
Time
Baseline end date
Forecast end date
Variance (weeks)
Escalation conditions (weeks)
Within escalation
conditions?
Baseline budget
Business case
Benefits
Budget
Forecast budget
Variance
Escalation conditions %
Within escalation
conditions?
Baseline benefits
Forecast benefits
Variance
Escalation conditions %
Within escalation
conditions?
Baseline profit
Forecast profit
Variance
Escalation condi-
Description
Name of the project
The project’s identifying code.
When the project was last subject to a health check or audit.
Who undertook the health check.
When the project was started formally.
The person charged with delivering a commercially successful outcome.
The people charged with authorizing the definition and acceptance of
the project’s outcome from a user’s perspective.
The people charged with authorizing the design and development of
a robust and reliable solution that will meet the user’s needs.
The person charged with planning, monitoring and controlling the
delivery of milestones to time, cost and quality expectations.
When the project will end as stated in the project governance report.
When the project will end as identified in the current project plan,
taking account of any actual or forecast variances.
The difference between the baseline end date and the forecast end
date.
The amount against which variance is compared to determine whether it should be referred to the portfolio management team.
a yes/no response.
The project’s intended budget as stated in the project governance
report.
The project’s budget as identified in the current project plan, taking
account of any actual or forecast variances.
The difference between the baseline budget and the forecast budget.
The amount against which variance is compared to determine whether it should be referred to the portfolio management team.
a yes/no response.
The project’s intended benefits as stated in the business case.
The project’s benefits as currently envisaged, taking account of any
actual or forecast variances.
The difference between the baseline benefits and the forecast benefits.
The amount against which variance is compared to determine whether it should be referred to the portfolio management team.
a yes/no response.
The project’s intended profit (the difference between project/operational costs and benefits over a defined period) as agreed
in the business case.
The profit as identified in the current business case, taking account of
any actual or forecast variances of costs and/or benefits.
The difference between the baseline profit and the forecast profit.
The amount against which variance is compared to determine wheth-
50
tions %
Within escalation
conditions?
er it should be referred to the portfolio management team.
a yes/no response.
As seen from Table 13, the repeater factor in almost each of areas is comparison between the baseline and the forecast. Though, the project register reports gives an
overview of the all projects in the portfolio, the portfolio management team might be
interested to see an overview of the portfolio on a corporate dashboard. Roberts thinks
that it is essential, however, that any report clearly indicates where and what corrective
action must be taken. Thus, the corporate dashboard also indicates where escalation
conditions have been breached so that further detail can be obtained from the project
register. The corporate dashboard is presented in Figure 15 below.
Figure 15. An overview of the portfolio (Roberts 2007: 175).
As seen from Figure 15, all the projects in the project register can be summarized further, giving the management overview of the portfolio. The corporate dashboard also
indicates where escalation conditions have been breached, so that further detail can be
obtained from the project register.
Thus, Roberts (2007) argues that project tools remain limited by the data they contain,
the people who operate them and the organization’s capacity to absorb them into its
working practices. Because of the complex nature of their installation, organizations
can be reluctant to implement software tools that may have to satisfy the needs of
many stakeholders and can affect working practices. Therefore, expectations of the
value they can deliver compared with the operational risk of their installation should be
carefully considered (Robert 2007: 19). This may draw the conclusion that in many
51
companies improving the current tools might be a less risky way to gain efficiency than
implementation of some new software.
Thought reporting practices consist of many areas and report templates, as shown
above, they include the necessary data for particular stakeholders. In addition, the convenience of their use and utilization in the projects is also a matter of technology and
tools used for reporting, as well as suitable reporting practices adjusted to the needs of
a particular company. Data sources and tools that are used for reporting purposes may
finally determine how rich and accurate is the data utilized in the projects and how effectively the data is available and definable for reporting.
4.5
Conceptual Framework of This Thesis
In this study, the challenges found in the current state analysis and related to project
reporting related challenges was selected to be investigated in more detail. Main questions that were concluded from the remaining challenges in project reporting realm
were. a) what to control when reporting, b) how and when to report, and c) by what
means to carry out the reporting. These questions were the cornerstones of a more
detailed investigation of existing knowledge and best practice available in the literature.
In this study, the findings related to reporting identified from best practice and existing
business and academic literature were summarized according to the logic shown in
Figure 16 below. For project management reporting is found to play a vital role to control, steer, and monitor the projects. Project reporting characteristics are divided into
three main segments: 1) Project Controlling, 2) Project Monitoring, and 3) Project Reporting.
Figure 16 below summarizes the conceptual framework of this study.
52
Figure 16. Conceptual framework of this study.
In this framework, project controlling includes control mechanisms that are commonly
used and developed based on empirical knowledge in project work. Project controlling
emphasis importance of different sub-areas in this realm, but also suggest to take into
account relationship between the sub-areas and their influence on each other. Project
monitoring takes into account needs from different stakeholders of a project. As reporting needs varies depending on a stakeholder group, existing knowledge explains what
the interests of each stakeholder group are. Project reporting summarizes practices of
project reporting, giving suggestions in what means reporting could be done with suitable reporting templates. It also explains project reporting and information gathering
cycles.
The three areas which were explored in this section relate were steered by the more
general questions which were identified as a result of the current state analysis (What
to report, how and when to report, and by what means to report).
The next section applies the identified best practice to approach the problems identified
in the case company.
53
5
Building Proposal for the Case Company
This section develops a proposal to improve the current reporting practices in the case
by matching the areas for improvements identified from the current state analysis and
the findings suggested by best practice. The proposal is developed by involving the
relevant stakeholders in the proposal building process.
5.1
Challenges in the Current Reporting Practice
In this study, the challenges found in the current state analysis were analyzed and project reporting related challenges was selected to be investigated in more detail. Main
questions that were concluded from the remaining challenges, from the project reporting point of view, were: a) what to control when reporting, b) how and when to report,
and c) by what means to report. These questions were the cornerstones of a more detailed investigation of existing knowledge and best practice which was done in the previous section.
The current state analysis discovered the challenges related to the project reporting
practices in the case company. The findings suggest that the project reporting challenges are mostly related to either lack of a reporting practices in offshore reporting, or
missing data or a certain lacking reporting tool. These challenges presented earlier in
Section 3 are briefly summarized in Table 14 below.
Table 14. Project reporting challenges in the case company.
Problem Area
Description
1.
No common and formal report
for reporting from offshore to
onsite
2.
The project accounting tool for
Portfolio management reporting is inadequate
Finance Forecast report is
missing some practical financial information
There is a need for having progress report from offshore
in a form that the current weekly report does not support. Practices and content of offshore reporting varies
project by project.
Excel tool is non-uniform with Portfolio Management HC
report data. It requires additional information and conformity in accordance with HC.
Lacking of some financial information causes extra
work. Adding some recognized information in tool might
save worktime and increase accuracy of the data.
3.
Table 14 shows that two of the problems are related to project reporting practices and
one of them is related to the reporting tools. The project accounting tool for portfolio
54
management requires significant improvement whereas the finance forecast report
could be improved with minor changes.
The current reporting practice of the case company requires regular reporting on
agreed form. The case company has several lines on reporting and different reporting
cycles depending on the reporting line. Some of the reporting lines and cycles are presented in Figure 17 below.
Figure 17. Reporting lines and cycles in the case company.
Figure 17 is an illustrative model of the current reporting practice, showing four reporting lines in the case company Project delivery process. The green circles reflect the
reporting frequency, for example, in Line 1, the Portfolio management, receives their
report every four week. Line 2, Steering group, also receives a report every four weeks,
but their reporting cycle is often related to the progress in a project in general and various project phases. The customer (Line 3) receives their weekly report every week and
the offshore team (Line 4) is expected to report their progress also on a weekly basis.
Reporting responsibilities are divided so that the offshore project manager reports on
the project progress to the onsite project manager. The onsite project manager is responsible for reporting to the customer, steering group and portfolio management
group.
55
5.2
Reporting Improvements and Suggestions from Team Discussions
The current reporting challenges were discussed several times with interviewees and
some other people around the service delivery business department of the case company (Data 2). Based on the discussions with the stakeholders in the case company,
the reporting related discussions and suggestions can be summarized as follows.
A. Onsite and offshore use different templates for reporting
The current practice of offshore progress reporting from the offshore project manager
to the onsite project manager varies project by project. Often a particular reporting
practice is agreed between the project managers upon starting the project and thus,
they are not uniform in this area. When discussing the suggestions for improvement in
this area, the stakeholders who participated in Data collection 2 specified even further
their vision of the challenges (so that to better argue for their suggested solutions). The
interviewees stressed that the current practice suffers from these challenges such as:
a) reported data is often not uniform with data required for the customer weekly report,
b) as reporting in this area is not formal, the confidence in accuracy of information is
suffering, and c) though, something has been agreed to be reported between project
managers, very often asked data comes in different form than expected. One interviewee commented on this problem area as:
Even though we agreed in the beginning of the project what to report, all I got is a
report, which shows roles and their allocation in the project and progress of project phases. It would be more convenient to have names instead of roles, their
costs and overall information that makes match with customer weekly report, but
in more detailed level.
(Person 7)
In addition to this, other interviewees commented in a workshop that they would like to
have more information about comparison between baseline and forecast. Therefore,
the interviewees suggested that the starting point for the improvement of this area
could be a uniform customer weekly report, which could be used as a model. They argued that, if the data is possible to receive from offshore in the same format, though on
a more detailed level, it is easy to fill in the customer weekly report and thus save time
and reduce probability of an error in the data. Overall, the improvement in this area
requires, according to the team, mapping of the current practices in all projects and
based on the most effective practice and experiences, define the required information
that is needed from offshore on a weekly basis and piloting of the new offshore weekly
report.
56
Meanwhile, until this is not done, the team has agreed that the following items should
be included in the weekly report from the onshore team. First, the completion level of
each task assigned to the offshore team. This information should be expressed as a
percentage. Second, the forecast of each parameters such as schedule, completion,
costs and resource allocation. It is noteworthy that forecast should be always compared to the baseline and if any deviations occurs, they must be raised. Third, any indicated problems must be reported clearly and promptly. Overall the information provided
by the suggested weekly report should make match with the customer status report.
Based on these suggestions, the new template was developed that incorporated the
stakeholders’ suggestions (as shown in Appendix 7).
B. Project Accounting Tool is Inadequate for HC Reporting
When discussing the suggestions for improvement in this area, the stakeholders who
participated in Data collection 2 stressed that the current practice suffers from the following challenges: a) data fields in both the tool and HC report mismatch in some places, b) the tool does not provide all required data for HC report, c) the current data from
the tool is ambiguous in places, and d) the tool does not provide any help texts. The
practical problems of use of the tool were commented as follows:
Filling HC report is really time consuming task, it takes several hours to collect all
required data from different sources and looks like the tool provides only one portion of the data for HC report. Though, some data can be found from the tool, it
often requires some extra calculation and extra data added in the tool in order to
finalize figures for HC report.
(Person 2)
Other person also commented on this challenge area as follows:
If the tool could provide clearly same data with same field names than we have in
HC report, it would be very beneficial tool. That could save a lot of project managers’ work and create confidence against the accuracy of data.
(Person 11)
Due to these facts, the stakeholders emphasized that the change to the tool will need
to be relatively large and it will also require a detailed mapping of the current needs
and requirements against the tool. Once the needs and requirements are clear, changes ought to be implemented and after that carefully piloted. The pilot of the tool might
raise up new needs or require some related fine-tuning, so this should be taken into
account before launching the tool for larger use.
57
Based on the Data 2 collection, the following features should be included in the project
accounting tool. First, the information calculated and provided by the tool should match
with the HC report. Additionally, the tool should include calculation for the fields in the
HC report that are not calculated currently in the tool. Second, additional information
about the fields in the tool and some help information should be included in the tool.
Overall, the information provided by the tool ought to be aligned according to the HC
report in order to save time and reduce possibility of an error in financial data.
Based on these suggestions, the improved proposal was developed that incorporated
the stakeholders’ suggestions.
C. Finance Forecast Report Lacks Information
When discussing the suggestions for improvement in reporting area, the Finance forecast report has identified as the first and easiest improvement target by the interviewed
stakeholders. The current challenges with the report are related to two missing types of
information: the resource allocation (in percentage) and revenue information. Though
the suggested improvements are not relatively big, they were considered to save time
and increase efficiency as one interviewee put it:
The finance forecast report is in good shape now, though it requires some manual work as feeding project actual hours weekly, it would help to save time it the
report would allow resource allocation filling with percentages, instead of hours. It
also would be beneficial to have revenue information from the report as it is missing currently.
(Person 2)
The suggested improvements to Finance forecast report are expected to require but a
light effort to be implemented. However, it would be beneficial to collect any other
needs from project managers and plan their implementation simultaneously with the
suggested improvements. If all suggested improvements are still relatively small, they
could be implemented and taken into use without piloting.
The improvement proposal for the Finance forecast report includes the following: a) the
current allocation information presented in hours should be replaced with percentages,
ad b) revenue information should be present as it is lacking currently.
58
If summarized, the current reporting challenges discussed with the stakeholders in the
Project delivery process in the case company (Data 2) pointed to the following suggestions, as summarized in Table 15 below.
Table 15. Suggestions for solving the current reporting challenges.
Problem Area
Suggestion
1.
No common and formal report
for reporting from offshore to
onsite
2.
The project accounting tool for
Portfolio management reporting
is inadequate. The tool is missing some information and help
texts
3.
Finance Forecast report is missing some practical financial information
To create new report for offshore, that serves onsite team as well as the customer.
Preliminary required information includes:
 completion-%
 forecasts
 clearly stated problems
 compatible with customer status reporting (high
and detailed levels)
Additional information and help information in the
tool in order to ease use of it and to confirm the
reliability of the information.
Information in the tool ought to be aligned according to the HC tool. This saves lot of time and reduce possibility of an error in financial data.
To add at least the following information in the finance forecast report:
 Allocations in percentages instead of hours
 Revenue information
As seen from Table 15, the current challenges in the case company are visible in three
areas: a) Onsite and offshore use different templates for reporting, b) The project accounting tool is inadequate for HC reporting, and c) Finance forecast report missing
information. Improvements and suggestions for these challenges are discussed in
more detail below.
Improvements and suggestions for these challenges were discussed with the team and
formulated into the proposals for improvements. The first proposal relates to the New
Uniform Template for reporting on project progress for Onshore and Offshore teams.
This Template is proposed for a weekly reporting (created based on the stakeholders’
suggestions and shown in Appendix 7). The second proposal relates to the Improved
Project Accounting Tool. The proposal includes recommendations for improving the
tool by new features such as calculating uniform data for HC report and providing help
information for the user. The third proposal relates to the Improved Finance Forecast
Report. This Report is recommended to include features such as replacing hour related
resource allocation information by percentages and providing revenue information.
59
Summing up, the smallest effort was needed to implement corrections for the Finance
forecast report (Proposal 3) as it requires only little additional information. Creating a
new Template for offshore reporting (Proposal 1) required more effort, and it was recommended to put this proposal into a limited use in the beginning in order to test and
validate this reporting practice. The Project accounting tool for portfolio management
report (Proposal 2) was estimated to save time in the future if the suggested corrections are made. This change needs the most effort compared to other suggestions to
the current reporting practices. As the output of the project accounting tool is the financial data for the HC report, its accuracy has especially important. Therefore, the stakeholders also suggested to plan for the piloting and collecting experience and feedback
from the pilot, which was put into the Action plans presented as part of the proposal
below.
5.3
Action Plans for Implementing the Improvement Suggestions in Reporting Practices
Suggestions for improvements to the current reporting practices were formulated into
the following three outcomes which should positively impact the current reporting practices. The description below identifies the outcomes, first, separately and then point to
the changes on the reporting map.
A. Implementing the Uniform Template for reporting on project progress for Onshore and Offshore teams (New)
Based on best practice from literature, the first draft and proposal for the new offshore
reporting template is presented in Appendix 7. The report template includes core information that is usually needed for progress reporting in the case company. However,
the report template can be modified further on and there is room for improvements reserved in the action plan, presented in Table 16 below.
Table 16. Action plan for implementing the uniform report template for offshore reporting.
Step
1.
Action
Evaluation of the current state of reporting in the Project delivery,
a) Successful practices from the current project(s)? (in which new reporting is
applied)
b) More needs for reporting? (content, cycle..)
c) Possible reporting tool changes within this project? (as for accuracy of the information, etc.)
60
2.
Correcting the Report template and practices based on the discovered needs, requirements and best practice from the project(s).
Piloting the updated Report template with the new selected project managers and projects (for 3 months)
Gathering feedback from the pilot, fine-tuning the Report template and practices (if
necessary)
Launch into larger use.
3.
4.
5.
Table 16 above includes five steps action plan for improving offshore progress reporting. Recommended draft template (Appendix 7) acts as a starting point for planning
needs in the step 2 as it helps to concretize needed changes.
B. Implementing the Project Accounting Tool (Improved)
The project accounting tool requires changes that eases use of it and also provides
more information for the HC report. The plan on how to proceed with mapping the
needs and implement them are presented in Table 17 below.
Table 17. Action plan for improving the Project accounting tool.
Step
Action
1.
Mapping of the current state of reporting in the Project delivery,
a) Collecting experiences from the use of this tool from the Project Managers
b) What data is needed to add and to calculate in the tool?
c) What help information is needed?
d) What needs are not addressed?
2.
Updating the tool based on these feedback and needs
3.
Piloting the tool with a selected project managers and projects for 3 months
4.
Gathering the feedback from the pilot, fine-tuning of the tool (if necessary)
5.
Launch into larger use.
As seen from Table 17 the steps follow same pattern as the previous action plan (Table
16). Goal of the project accounting tool improvement is to increase available data from
the tool (Appendix 1) to match with the HC report (Appendix 2).
C. Implementing the Finance Forecast Report (Improved)
The proposed improvements for Finance forecast tool are relatively small to implement.
Action plan for improvements of the Finance forecast tool are shown in Table 18 below.
Table 18. Action plan for improving Finance forecast report.
Step
Action
61
1.
Mapping of the current state of reporting in the Project delivery:
1. Collecting experiences from the use of the tool from the Project Managers
2. What financial data is needed to add and to calculate in the tool?
3. What other information is needed?
4. What needs are not addressed?
2.
Updating of the tool based on these feedback and needs
3.
If the changes are minor:
1. Fine-tune
2. Launch into larger use.
4.
If the changes are major:
a) Pilot the tool with selected PM’s and projects for 3 months
b) Gather the feedback from the pilot; investigate and revise carefully; fine-tune
the tool.
c) Launch into larger use.
Table 18 shows that even though two improvement needs are already known, the current state of the Finance forecast report is need to be mapped. If any additional needs
will be found from that phase, they will be considered and in case the all improvements
form only minor changes, they will be implemented and launch into larger use. If the
proposed changes are major, the piloting following by feedback and fine-tuning will be
arranged before the launch into larger use.
Suggested corrections will have the following impact on the current reporting practices.
Figure 18 below identifies the proposed suggestions on the reporting map.
Figure 18. Mapping of suggested solutions.
62
As seen from Figure 18, the suggested improvements on reporting practices will have
impact on each of the reporting lines. However, improvements might have also an indirect impact on the reporting lines other than marked in Figure 18. For example, the
uniform weekly report will enable more reliable reporting forwarded to the customer and
steering group. Overall, the suggested improvements are expected to increase efficiency of reporting, save time of the project managers, and increase confidence in the
accuracy of reported data.
63
6
Validation of the Proposal
This section discusses the results of the validation of the preliminary proposal with the
management of the case company. It is followed by presentation of the final proposal.
6.1
Validation with the Management
Validation of the preliminary proposal was held with the management of the project
delivery department of the case company. The validation was arranged in a form of a
discussion session. The session started with overview of the identified challenges (Data 1) and data collection methods for Data 1, including description of the roles of interviewees, results from CSA and focus area of this study. Focus area related problems
were presented and discussed in detail, and also the identified best practice from the
literature were discussed. Finally, the preliminary proposal was presented to the management.
The management validated the preliminary proposal as suitable for the case company
needs in the project delivery process and approved of it. During the session, the management was asked to confirm the Action plans on how to proceed with the proposed
suggestions. The management confirmed that the Proposals including the Action plans
are considered as important and useful and will be implemented. It was also suggested
that a more detailed implementation plan to test in a suitable project will need to be
carried out within the continuous development stream in the Steering group.
6.2
The Final Proposal
Since the management had no any significant changes to the initial proposal, the final
proposal repeats the preliminary proposal. The final proposal is presented in Table 19
below.
Table 19. The final proposal, shown as three outcomes.
Main questions from
CSA to investigate
best practice from
existing knowledge
What to report (issues)?
Outcome 1: Report
template
Outcome 2: Improved project accounting tool
Outcome 3: Improved finance
forecast report
No common and
formal report for reporting from offshore
The project accounting tool for Portfolio
management report-
Finance Forecast
report is missing
some practical finan-
64
to onsite
How to report (process)?
By what means
report (tools)?
to
To create new report
for offshore, that
serves onsite team
as well as the customer.
Preliminary required
information includes:
 completion-%
 forecasts
 clearly stated
problems
 compatible with
the customer status reporting
(high and detailed levels)
Weekly, from offshore to onsite
Report template
ing is inadequate.
The tool is missing
some information and
help texts
Additional information
and help information
in the tool in order to
ease use of it and to
confirm the reliability
of the information.
Information in the tool
ought to be aligned
according to the HC
tool. This saves lot of
time and reduce possibility of an error in
financial data.
cial information
Monthly, to the portfolio management
Weekly to the customer,
Monthly to the steering group
Report template
Excel
To add at least the
following information
in the finance forecast
report:
 Allocations in
percentages instead of hours
 Revenue information
As seen from Table 19, the main questions presented in the CSA were utilized to find
suggestions from best practice (also visible in the conceptual framework) and answered in the final proposal. The thesis improved three key project reporting practices
as part of a wider reporting process in the case company Project Delivery process.
The final proposal tackles the problems by suggesting a proposal for the key problems
described in Sections 5.3 and 6.2. On a high level, for further refinement of the proposals it is suggested to do: a) a detailed mapping or evaluation of the proposals, b)
based on feedback from the previous phase, to do the necessary corrections, c) piloting and gathering feedback from the pilot, d) fine-tuning based on feedback from the
pilot, and e) launching into larger use. As the required work effort to solve the problems
varies between the suggested proposals and per problem, the following Figure 19 describes how the action plans should be carried out.
65
Figure 19. The schedule for implementing the suggested proposals.
Figure 19 shows what actions and when could be taken in order to improve the reporting practices in the case company as described in the action plans in Section 5.3. As
seen from Figure 19, each of the improvement proposal has its own launch schedule.
This is due to difference in work effort, required resources and stakeholders, which
vary between the proposals. However, all launches are planned to be executed in fall,
except for the improvement to the Finance forecast report, since its changes are minor,
which will be launched in June.
6.1
Managerial Implications
If the case company decides to improve its reporting practices, the management is
recommended to take the following actions.
First, to make decision in the Steering group of continuous development stream to
nominate a responsible person for each improvement area. Once the responsible person of each area has been nominated, an Action plan, as described in Figure 19 in
Section 5.3, should be developed.
Second, the Steering group of continuous development stream should follow the progress and take the necessary decisions during the process as for: a) allocating resources, b) deciding on the extension of suggested changes, taking into account the
costs involved, c) starting the pilot, d) deciding on the launch of improvements into
larger use, taking into account the necessary announcements, updates to instructions,
process diagrams and other internal documentation and any other area that might be
affected due to improvements.
66
Third, there is a recommendation to continue collecting improvement ideas in this area
which should result in better project outcomes for the case company.
67
7
Discussion and Conclusions
This section discuss the main findings of this study, practical implications for the proposal and the next steps of the reporting practice improvement in the case company for
the future. It also evaluates the study by comparing outcome and objective of this thesis. Finally, reliability and validity of the study are discussed.
7.1
Summary
This study investigated challenges in the current processes in the project delivery business of the case company, with the focus on improving its reporting practices. Outcome of the study was the improvement proposal for three main challenges identified in
the current reporting practices.
The current state analysis investigated the project delivery business challenges in both
processes (the Work order and Project delivery processes). As a result of this investigation, totally 53 findings were identified in both processes, categorized and prioritized
with the interviewed stakeholders. The identified range of the challenges was relatively
large, comprising several challenge areas in both processes. Therefore, the focus area
of this study was chosen to be the improvement of the current reporting practices.
The current state analysis summarized main challenges in reporting area and presented three main questions that become the basis for searching solutions to the problems
from literature and best practice. Based on the current state analysis, the three main
questions to explore topic in existing knowledge were formulated as: a) what to report,
b) when and how to report, and c) by what means to report. As a result of literature
investigation, the conceptual framework of this study was formed.
End results from the both, the current state analysis and conceptual framework, were
used for building the preliminary proposal. The preliminary proposal evolved during the
building phase based on the inputs and comments from the stakeholders in the case
company. Development of the preliminary proposal called for several feedback rounds,
workshops and one-to-one discussions with the personnel.
The proposal included the following suggestions how to improve the current reporting
practices. First, the new Report template was proposed for offshore reporting. Second,
68
the improvements were proposed to the Project accounting tool, which includes the
additional data and help information added in the tool. Third, the improvements to the
Financial forecast report were proposed, which included two additional information
added in the tool such as resource allocation (in percentages) and revenue information.
These proposal addressed the challenges revealed from the current state analysis in
reporting practice in the case company. The most significant problems in reporting area
were identified as: a) offshore and onsite have no common and formal report Template,
b) the Project accounting tool for portfolio management reporting is inadequate, and c)
the Finance forecast report is lacking information.
Once the preliminary proposal took its final form, it was validated with the management
of the project delivery business department of the case company. Validation resulted
with only minor suggestions to the preliminary proposal, making it the final proposal.
The final proposal and its implementation were approved by the management and also
other findings from the current state analysis stage were agreed to be followed caseby-case with the Steering group of continuous development stream in the case company.
7.2
Practical Implications and the Next Steps
The final proposal of this thesis is expected to improve the current reporting practices
in the case company. The reporting between onsite and offshore should be consists,
uniform with other reporting lines and formal. Improvements of reporting tools are expected to gain effectiveness in form of saved time, accuracy of data and uniformity.
Actual benefits from the outcome of this study will be revealed in more detail with time.
Therefore, one viewpoint on efficiency is to consider possibilities to measuring efficiency of proposed improvements.
As this study investigated only one part of the reporting practices in the case company,
it leaves room for larger investigation in reporting practices area. As this study already
revealed some improvement targets, that are expected to bring in efficiency and uniformity in reporting, mapping and investigating the whole reporting practices in the case
company could benefit from experience and best practice suggested in this study. Such
an investigation should take into account the whole reporting practices bottom-up.
Things to consider are: a) data sources; technology used for storing, handling and re-
69
fining data, b) all used tools for analyzing and producing data for a report, c) all used
report templates and d) target stakeholders of the reports and their needs. Drawn map
of the whole reporting in the case company, which includes all previously mentioned
topics, gives overview of the current state of the whole reporting practices in the case
company. Such a map alone could already reveal, for example, overlapping of the data
sources or inefficiency of sharing information between the different stakeholders,
though access to root problems requires deeper analyzing and investigation of selected
challenge areas.
7.3
Evaluation of the Thesis
This section evaluates the outcome against the objective of the study. It also discusses
reliability and validity of this study.
7.3.1
Outcome vs Objective
The outcome of this study is the final proposal, which includes three improvement suggestions and action plans for each improvement on how to proceed in order to implement them. Improvements are related either to the existing report, weekly report template or the existing reporting tool.
The main objective of this study was to improve the project reporting practices in Project Delivery business. The improvement proposal had to address the suggestions for
improving the current reporting practices in the case company.
One aspect of the objective was to define three main questions that were asked in the
current state analysis to approach the search for solutions from best practice. Those
questions were: a) what to report, b) how and when to report, and c) by what means to
report. These questions were concluded from the identified challenges in the reporting
area and were used to conduct the literature search. Existing knowledge and best practice provided answers to the questions and literature combined with the current state
analysis helped to produce the final proposal. To address the first question, a new
weekly report (Appendix 7) was prolapsed to meet the preliminary need for reporting
between offshore and onsite. However, as stated in the final proposal, the content and
other needs for weekly report template will be further mapped in more detail according
70
to the action plan. Consequence of the second question was the improvement of the
existing report in order to increase its efficiency and feasibility. As a result of suggested
improvements, it is expected to provide more financial information and thus increase
the level on what to report to different stakeholders. Regarding the third question, suggested improvements to the project calculating tool creates conditions for efficient reporting, as improvements are expected to save time and increase accuracy of data.
Hence, the improvements on the tool were aimed to match with the HC report data and
thus emphasize the reporting tool used for reporting.
Summing up, the outcome of this study provides three different improvements to the
current reporting practices in the case company. As the objective of the study was to
improve the project reporting practices in the case company, it can be considered that
the objective has been achieved.
7.3.2
Reliability and Validity
This study is based on qualitative research methods, following action research as it
research approach. Part of the action research is reliability and validity plan, which is
described in Section 2.4 in this study.
As for validity the outcome of this study met the objective as was promised in the beginning of the study. The explanation in the thesis took into account correctness and
credibility of a study by descriptions, conclusions, explanations and interpretations. The
study made an effort to avoid the researcher bias by choosing the respondent group of
interviewees extensively, interpreting the data results with interviewed people, discussing the results and the proposal with many stakeholders in the case company and finally considering the rival proposals for the improvement solutions.
In order to improve reliability, the data collection, analysis and conclusions from the
data were described in detail. Part of the data collection were the interviews, which
were recorded and drawn into the field notes. Though the number of interviewees were
limited and thus they mostly took into account needs from onsite, in some cases it
would have been beneficial to interview more people from offshore. Findings from the
interviews, and thus recorded and drawn down into field notes, were recorded in an
excel spreadsheet. Moreover, all the findings from the excel sheet were presented to
71
the interviewees and prioritized and analyzed with them. Additionally, the preliminary
proposal was discussed several times with different people from the case company and
thus gained validity. One other way to increase validity was to quote directly few interviewed people to detail the challenges reported in this study.
Reliability of this study was increased by using at least three different data sources that
were internal documents, interviews and discussions and observations. Internal documents exposed the current reporting practices including report templates and used
tools. Interviews and other discussions gained the knowledge learned from internal
documents and existing reporting practices in the case company. Common meetings
with interviewed people helped to mutually understand the reporting related challenges.
To enabling verisimilitude, the outcomes of the study were discussed widely with colleagues in order to challenge the solution. The preliminary proposal of this study was
validated with the interviewees and finally with the management of the project delivery
business organization of the case company. Part of the validation was to question proposed proposal and try to find solution for the challenges from the rival solutions such
as existing practices. Validity of the outcome of the study was hereby discussed extensively in the case company.
7.4
Final Word
IT field is generally known as rapid changes in technology and business. The changes
force IT companies to reconsider and challenge the current business processes and
practices in order to response changes in the business environment. As a result of this
change, some IT companies might have renewed needs for example toward reporting
practices. Initiative for such a change could be for example acquisition, outsourcing,
new customer relationship, partnership and so on. This said, the current reporting practices might be under pressure to change over time in some IT companies. Every company needs reporting, therefore improvements in reporting may help companies in
monitoring their progress better, detecting performance earlier and predicting needs for
change earlier.
72
References
Cane, A. (2007). Why Do So Many Technology Projects Fail? November 20, Financial
Times.
Ciampa, D. (1992) Planning for Successful Steering Committees. The Journal for Quality and Participation. Vol. 15(7), 22.
Chemuturi, M. (2013). Mastering IT Project Management: Best Practices, Tools and
Techniques. Plantation, FL, USA: J. Ross Publishing.
Coghlan, D. and Brannick, T.(2006). Doing Action Research in Your Own Organization.
London etc.: Sage Publications.
Ditmore, J. (2011). Ensuring Project Success: Best practices in Project Delivery. 24
December 2011. Blog. Available from: http://www.recipeforit.com/2011/12/24/ensuringproject-success-best-practices-in-project-management/ [Accessed 18 April 2015]
Golafshani, N. (2003). Understanding Reliability and Validity in Qualitative Research.
The Qualitative Report, Vol.8 (4), 597-606. Available from
http://www.nova.edu/ssss/QR/QR8-4/golafshani.pdf [Accessed 26 February 2015]
Hulett, D. (2009). Practical Schedule Risk Analysis. Abingdon, Oxon, GBR: Ashgate
Publishing Ltd.
ISO 9000 Standards (2005). Quality Management Systems – Fundamentals and Vocabulary. [WWW Document] https://www.iso.org/obp/ui/#iso:std:iso:9000:ed-3:v1:en
[Accessed 25 April 2015]
Lewin, Kurt (1958). Group Decision and Social Change. New York: Holt, Rinehart and
Winston.
Manning, S, (2010). Embedding Projects in Multiple Contexts: A Structuration Perspective. International Journal of Project Management. Vol. 26 (1), 30-37.
Mittas, N., Mamalikidis, I. & Angelis, L. (2015) A Framework for Comparing Multiple
Cost Estimation Methods Using an Automated Visualization Toolkit. Information and
Software Technology. Vol. 57, 310-328.
Patel, V. (2008). Project Management. Jaipur. Oxford Book Co.
Porter, M.E. and Rivkin, J.W. (2012). Choosing the United States. Harvard Business
Review. Vol. 90 (3), 80-93.
Roberts, P. (2007). Guide to Project Management. London, GBR: Profile Books/The
Economist.
Quinton, S., & Smallbone, T. (2006). Postgraduate Research in Business. A Critical
Guide. SAGE Publications Ltd.
Appendix
1 (9)
APPENDIX 1: The Summary Project Forecast Report
Appendix
2 (9)
APPENDIX 2: The Project Time Forecast Report
Appendix
3 (9)
APPENDIX 3: The Cost Forecast by Type Report
Appendix
4 (9)
APPENDIX 4: The Cost Forecast by Product Report
Appendix
5 (9)
APPENDIX 5: The Project Quality Forecast Report
Appendix
6 (9)
APPENDIX 6: The Benefits Forecast Report
Appendix
7 (9)
APPENDIX 7: New Weekly Report Template
Background
Project name
Software Development Project
Report date
24.4.2015
Week number
17
Assessor
Highlights
Progress to date has been per plan except 100 hours crossing in baseline
effort due to issues in the definition phase.
The user requirements document has commenced with completion expected
to plan.
Time
Milestones
Cost
Baseline end date
31.8.2015
Forecast end date
31.8.2015
Variance
0
12 identified deliverables or milestones of which:
10
in green
2
in amber
0
in red
Baseline budget
250 000 €
Forecast budget
250 000 €
Variance
0€
Baseline effort
3 900 hours
Forecast effort
4 000 hours
Variance
100 hours
Phase/task
%
variance
Definition
80 %
+100 hours
Design
60 %
Development
40 %
Testing
10 %
Deployment
1%
Overall
70 %
Effort
Completion
Appendix
8 (9)
APPENDIX 8: The Current Project Accounting Tool
Appendix
9 (9)
APPENDIX 9: The Estimates and Financial Tabs of the HC Report
Estimates Tab:
Financial Tab:
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Related manuals

Download PDF

advertisement