=Paper=
{{Paper
|id=Vol-1985/BPM17industry08
|storemode=property
|title=The Project Start Review Group
|pdfUrl=https://ceur-ws.org/Vol-1985/BPM17industry08.pdf
|volume=Vol-1985
|authors=R.J. Macasaet
|dblpUrl=https://dblp.org/rec/conf/bpm/Macasaet17
}}
==The Project Start Review Group==
https://ceur-ws.org/Vol-1985/BPM17industry08.pdf
The Project Start Review Group
RJ Macasaet1
1 Digital Management Inc., Barcelona, Spain
rmacasaet@dminc.com
Paper Submitted on May 22, 2017; Accepted for Publication on June 16, 2017
Abstract. Multinational software organizations typically have numerous pro-
jects with varying technical requirements, resourcing needs, and time frames.
This is a complex situation and if not handled properly, could result in multiple
project failures and the demise of the software organization altogether. The Pro-
ject Start Review Group or “SRG” as we call it in our organization, follows a
daily business process to ensure the best possible start for all projects. SRG is
made up of a global resource manager and key representatives in various lines
of expertise, in several locations around the world. These key representatives
are leaders in project management, sales and account management, user experi-
ence and user interface design, software development and architecture, quality
assurance and testing, and software applications maintenance. We refer to these
lines of expertise in our organization as workstreams. SRG has been syncing
these various workstreams in multiple locations all around the world and has
been enabling our mobile applications and responsive websites team to deliver
successful projects since 2005.
Keywords: Software Organization, Multinational, Project Management, Risk
Management, Resource Management, Capacity Management
1 Introduction
Multinational software organizations typically have numerous projects with varying
technical requirements, resourcing needs, and time frames. This is a complex situation
and if not handled properly, could result in multiple project failures and the demise of
the software organization altogether.
The industrial context of our work involves multinational organizations, with more
than 10,000 employees and more than 1 Billion US Dollars in revenue, that have
software delivery contracts with multinational software organizations with around
2,000 employees and 200 Million US Dollars in revenue. The size of each software
project ranges from 500,000 to 10 Million US Dollars and involves around 20 to 100
people located in several locations in different time zones around the world. The av-
erage duration of a software project is around 6 months. Software organizations of
M. Brambilla, T. Hildebrandt (Eds.): BPM 2017 Industrial Track Proceedings,
CEUR-WS.org, 2017. Copyright © 2017 for the individual papers by the papers' au-
thors. Copying permitted for private and academic purposes. This volume is published
and copyrighted by its editors.
RJ Macasaet
this size have around 100 projects running at any point in time and at the end of each
year, will have delivered around 150 of them.
Business processes have to be established in large software organizations to ensure
that multiple projects could start in the best way possible. This paper presents one of
the business processes followed by our team, the mobile applications and responsive
websites delivery team, at Digital Management Inc. [1].
2 Techniques and Methods Applied
The Project Start Review Group or "SRG" is a group which ensures that all projects
start properly. SRG is made up of a global resource manager and key representatives
in various lines of expertise. These key representatives who are located in different
locations around the world are leaders in project management, sales and account man-
agement, user experience and user interface design, software development and archi-
tecture, quality assurance and testing, and software applications maintenance. We
refer to these lines of expertise in our organization as workstreams. In order to syn-
chronize the delivery of various software projects involving several workstreams
around the world, we follow our daily SRG business process as illustrated in Figure 1.
First, we go through the pre-sales opportunities created by the account managers in
our sales team and based on the availability of resources in the workstreams, we as-
sign a pre-sales team composed of a technical contact which is usually a project man-
ager or lead developer, a design contact, and a solutions architect. When the pre-sales
opportunity has the team members it needs, the team works on the opportunity until
the customer is ready to sign a contract and start a project with us.
Second, we go through the pre-sales opportunities that have reached maturity and
are contenders for a project to start. The technical contact of the pre-sales opportunity
presents the Five Start Criteria to SRG which are:
(1) A detailed project scope
(2) Workstreams identified (e.g. iOS, Android, Backend (Java), Design, etc.)
(3) Estimates per workstream and estimated project timeline
(4) Estimated start and end dates of the project
(5) A signed contract with the customer or written approval to start by the
CEO/COO
SRG approves or rejects a project to start based on these Five Start Criteria.
Third, we go through the projects that have been approved to start and are ready for
resourcing. The global resource manager presents the possible teams that could work
on the approved projects. These team setups are a result of resourcing processes per-
The Project Start Review Group
formed by the global resource manager and key workstream leads prior to the SRG
meeting as discussed next.
A workstream lead is the most qualified person in the workstream who can rec-
ommend others in their own workstream to do project work. Usually, this person is
the most experienced and knowledgeable person in the workstream and has the re-
spect of the colleagues in the workstream. Everyone else in the workstream will nor-
mally ask this person for advice when they are unable to solve a technical problem.
The global resource manager works with the workstream leads in the involved
workstreams, as specified in the Five Start Criteria, in order to determine the possible
candidates who can work on the project.
Fig. 1. The Project Start Review Group “SRG” Process.
When a set of candidates per workstream is proposed, the global resource manager
and the assigned technical contact try out several team permutations which could be
visualized with a team chemistry matrix as shown in Figure 2.
RJ Macasaet
In order to find out the best team permutation possible, it is necessary to break
down the team setup into relationships among the individuals. Relationships between
the individuals could be seen as good, neutral, or bad. They could be represented in
the team chemistry matrix with colors or numbers: green, yellow, red, or 3, 2, 1, from
best to worst, respectively. Factors such as culture, geographic location, seniority,
individual goals, and communication skills are taken into consideration when coming
up with the relationship assessments. The team chemistry matrix with the most greens
or with the highest score is usually the team that is recommended to SRG for approv-
al.
Fig. 2. Example of a Team Chemistry Matrix.
SRG will either approve or reject the proposed team. If the team is rejected, the
global resource manager will try to propose another team on the following day. If the
team is approved, the global resource manager relays the approval of SRG to the
workstream leads and then the project is officially kicked-off by the assigned project
manager.
Fourth, we go through the ongoing projects that need more resources or ongoing
projects that no longer need some or any of their resources. The project manager re-
submits the Five Start Criteria and if this is approved by SRG, the project is re-
resourced, taking into account the modifications, and then delivery of the project re-
sumes. If the modifications are rejected by SRG, then the Five Start Criteria are re-
done by the project manager and re-submitted to SRG on the following day.
Finally, we go through any other business or the AOB part of SRG. This final leg
allows SRG members to mention anything important that the group may have missed
during the day or anything that the group must anticipate for the next day.
The Project Start Review Group
3 Results of the Process
The SRG process has evolved from a short conference call across continents into an
organized, structured, and process-oriented daily meeting involving a global resource
manager and workstream leads. Today, the SRG process enables our software organi-
zation to start several projects at different points in time in an organized and struc-
tured way.
Aside from being more structured and organized in our day-to-day operations, one
of the positive effects that could be attributed to the SRG process is the elimination of
a substantial amount of risk when projects start, a time which is very crucial to overall
project success. As the SRG process has matured through the years, we observed that
the team setups were getting better and better. When teams are as co-located as possi-
ble, have the proper skillset and domain knowledge as recommended by the
workstream leads, and have high chemistry as recommended by the global resource
manager, then the chances that the software project will be successful could increase.
4 Discussion and Lessons Learned
Aristotle once said, “the whole is greater than the sum of its parts.” Considering team
chemistry when starting projects in a software organization could eliminate unneces-
sary risk at the start of the project and consequently contribute to overall project suc-
cess. Several software organizations still continue to staff their projects without con-
sidering team chemistry and still wonder why their projects keep missing deadlines,
go out of scope, and exceed budget.
We have learned that the workstream lead is the most apt person to recommend a
candidate or several candidates for a project. When technical project requirements
come up, those who are not technical experts could make several erroneous assump-
tions regarding the skills and capabilities needed to accomplish certain tasks. For
instance, a project manager who has no technical proficiency in React Native [2]
should not be the one recommending the developers to work on a hybrid development
project [3], more so if such project manager has an over-confident or over-optimistic
attitude [4]. The one recommending the developers should be the workstream lead for
hybrid development which in this case would be a front-end developer proficient in
JavaScript [5] and hybrid solutions [3].
5 Advantages and Limitations
An assumed advantage of the SRG process is that it could work in a software organi-
zation of similar size and nature. The SRG process has been working properly in our
mobile applications and responsive websites team involving 300 people in 6 different
locations, with software projects that have around 25 people, with a duration of
RJ Macasaet
around six months, and a delivery price of about 1 Million US Dollars. The imple-
mentation of the SRG process in a similar software organization could produce simi-
lar positive results.
As per limitations, the SRG process could also be working in our case because we
are at the right point in time, size, and growth trajectory for a process like this. It is
unlikely that the SRG process would work for a small-to-medium-sized business or a
micro-business [6][7]. On the other end of the spectrum, the SRG process may unlike-
ly work in really huge software organizations with projects involving 300 to 500 peo-
ple, with a duration of three to five years, and delivery prices exceeding 50 Million
US Dollars.
6 Future Work
The SRG process continues to evolve up to this day. It could mature further or could
be abolished altogether depending on the needs of our organization. In any case, the
SRG process could still be applied by any other software organization involving sev-
eral workstreams in different locations around the world. It would be interesting to
have an industrial report in the near future on how the SRG process would work in
other software organizations of similar size and nature.
References
1. Digital Management Inc. Homepage, http://www.dminc.com, last accessed 2017/05/22.
2. React Native Homepage, http://www.reactnative.com, last accessed 2017/05/22.
3. IBM Corporation: Native, Web, or Hybrid Mobile App Development. White paper, Doc-
ument Number: WSW14182-USEN-01, (2012).
ftp://public.dhe.ibm.com/software/pdf/mobile-enterprise/WSW14182USEN.pdf, last ac-
cessed 2017/05/22.
4. Fabricius, G., Büttgen, M.: Project managers’ overconfidence: how is risk reflected in an-
ticipated project success?. In: Business Research Vol. 8, Issue 2, pp. 239-263. Springer In-
ternational Publishing (2015). doi:10.1007/s40685-015-0022-3
5. JavaScript Homepage, http://www.javascript.com, last accessed 2017/05/22.
6. Macasaet, R.J., Noguera, M., Rodriguez, M.L., Garrido, J.L., Supakkul, S., Chung, L.: A
requirements-based approach for representing micro-business patterns. In R. Wieringa, S.
Nurcan, C. Rolland & J.-L. Cavarero (eds.), Proceedings of the IEEE 7th International
Conference on Research Challenges in Information Science RCIS, IEEE, (2013). ISBN:
978-1-4673-2912-5. doi: 10.1109/RCIS.2013.6577703
7. Macasaet, R.J., Noguera, M., Rodriguez, M.L., Garrido, J.L., Supakkul, S., Chung, L.:
Representing Micro-business Requirements Patterns associated with Software Compo-
nents. In RCIS’13 Special Issue of Top Ranked Papers, Journal of Information System
Modeling and Design IJISMD, IGI-Global, (2014). doi: 10.4018/ijismd.2014100104