WDES 2014 paper: On the Identification of Factors that Promote High- Performance Projects in Distributed Development: Preliminary Findings of an Empirical Study of a Fortune 500 IT Multinational Company
Similar to WDES 2014 paper: On the Identification of Factors that Promote High- Performance Projects in Distributed Development: Preliminary Findings of an Empirical Study of a Fortune 500 IT Multinational Company
Enterprise Project Management using Primavera P6 EPPMIRJET Journal
Similar to WDES 2014 paper: On the Identification of Factors that Promote High- Performance Projects in Distributed Development: Preliminary Findings of an Empirical Study of a Fortune 500 IT Multinational Company (20)
WDES 2014 paper: On the Identification of Factors that Promote High- Performance Projects in Distributed Development: Preliminary Findings of an Empirical Study of a Fortune 500 IT Multinational Company
1. On the Identification of Factors
that Promote High-Performance
Projects in Distributed
Development
Offshore Development Center, ORG
Christiano Ayub - IT Development Manager
PUCRS University, Brazil
Sabrina Marczak
Marcelo Perin
Rafael Prikladnicki
Workshop on DSD, SECO, and SoS
Sept 28, 2014
Maceió, Brazil
3. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
DSD Issues 3
Miscommunication
Lack of a shared vocabulary
Lack of trust
Coordination difficulties
Lack of unified working processes
5. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
Expectations
• Projects will attend or exceed their
performance goals
5
6. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
Expectations
• Projects will attend or exceed their
performance goals
5
High-performance projects
7. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
Research question
• What contributes to a distributed
software development project to meet
or exceed its expected performance?
6
8. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
Our empirical study
• 1 large multinational organization
7
• Brazil
• USA
• India
• Malaysia
• Ireland • Russia
9. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
ORG
• Matrix structure
• Development to maintenance projects
• Waterfall model
• CMMI Level 3 but also informal processes
• Annual project roadmap
8
10. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
Process 9
Projects
definition
PrioritizationRequests
Business representatives Business analysts managers
Software team
Project
development
Clarifications
Business-
software reqs
translation
Software reqs analysts Business analysts
Software team
Project manager
11. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
Participants
• 11 participants
• 9.5 years @ORG
10
12. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
Participants’ profile 11
P1 Quality and Metrics Manager 12 years, Req Analyst, PM
P2 Career Manager 12 years, 1st BR employee
P3 PM Manager 20 years,American, Salesman
P4 Senior Dev. Manager 10 years, Developer
P5 Senior Dev. Manager 10 years, Dev, Dev Leader
P6 Senior Dev. Manager 10 years, Dev Leader,Architect
P7 Project Manager 8 years, Req Analyst
P8 Project Manager 10 years,Tester,Test Leader
P9 Project Manager 10 years, Dev,Architect
P10 Senior Dev. Manager 6 years, PM, Site Manager
P11 Senior Dev. Manager 4 years, PM - critical apps
13. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
Interview script
• “Looking back at the distributed software
projects you have participated on, please think
of one project that stood out and elaborate on
what you think that contributed to this project
to attend or exceed its performance goals.”
12
14. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
Findings
• 7 successful factors
• 5 issues or roadblocks
13
15. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
Factor 1
“introduces something new to the business that
helps it to quickly evolve and better attend the
market” (P6)
14
Enables the business and helps it to evolve
“how can we [IT dept] help ORG to do
business in a better way?” (P2)
16. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
Factor 2
“try to anticipate the estimated delivery date since
the faster the new system is in place the more likely
it is that it will be in sync with the current business
process” (P9)
15
Delivers what the business needs in a timely
manner
17. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
Factor 3
“to be flexible and fast in perceiving changes and
adjusting to them in order to keep the software
aligned to the business needs” (P1)
16
Has an alignment between the business needs
and the software requirements
18. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
Factor 4
“we need to be able to distinguish what is a wishful
and a desirable need” (P3)
17
Finds the balance between what the customer
‘wants’ and what the customer ‘really needs’
“it is challenging to know the business
processes in details...” (P2)
19. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
Factor 5
“our current org structure makes it hard to
communicate with others and clarify things when
needed” (P8)
18
Has a requirements engineering process that
efficiently and effectively defines what has to be
done
20. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
Factor 6
“knowing how to approach the business
teams” (P2)
19
Has an adequate and qualified team
“knowing how to identify who are the right
stakeholders and to establish connections with
them” (P11)
21. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
Factor 7
“we cannot forget that this is expected from any
software project” (P5)
20
Delivers on time, on budget, and with quality
22. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
Issue 1
“... they [senior management] need to realize how
much this structure delays reaching out who is
responsible for the business processes, the real
owners of the software demands” (P11)
21
To have a mediator between the business
department and the IT team
23. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
Issue 2
“it is only at testing time that we learn that business
rules have changed” (P7)
22
To validate requirements too late in the
development lifecycle
“prototyping could be used to validate the
requirements” (P2)
24. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
Issue 3
“requests to decide on the projects roadmap is not
made based on standardized business
requests” (P2)
23
To have poorly written software requirements
25. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
Issue 4
“we assume we know about the business” (P11)
24
To work based on assumptions
“but the organization changes so fast that it is
risky to assume the definitions from the
previous release are still the same now” (P6)
26. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
Issue 5
“we have this bad habit of adding things we think
that will help” (P7)
25
To implement improvements that were not
requested
“this pro-active behavior is often nosy” (P1)
27. S. Marczak, R. Prikladnicki, M. Perin, and C.Ayub
How does SEng helps ORG?
• Agile methods vs.Waterfall
• Centralized organization
• Imposed communication channels
26
28. Thank you for your attention!
Questions?
Comments?
Suggestions?
Sabrina Marczak
PUCRS
sabrina.marczak@pucrs.br
Presented by and Main contact for this work
Workshop on DSD, SECO, and SoS
Sept 28, 2014
Maceió, Brazil