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