Case Study Analysis: Project Management in Rapid Prototyping

This case study analyzes a rapid prototyping project involving Cocable and GE Company, highlighting critical issues in project management. The assignment examines communication breakdowns, particularly the incompatibility of CAD models and the lack of clear specifications. It explores the assignment of responsibility for project failures, suggesting that Cocable should bear the financial burden due to their failure to double-check RP specs. The case study offers recommendations, emphasizing the importance of clear communication, defined objectives, and early identification of limitations to ensure project scope correctness. The conclusion stresses the importance of stakeholder involvement and accountability throughout the project lifecycle for successful outcomes. The assignment also provides a comprehensive list of references for further study.

1
Rapid Prototyping
Name
Course
Professor
School
Date

2
Table of Contents
Introduction...............................................................................................................................................3
Case study assessment:..............................................................................................................................3
What lesson can be learnt in this case?............................................................................................3
Who do you think should pay for the changes?...............................................................................4
Recommendations:....................................................................................................................................4
What could have been done to make sure that the project scope was correct?............................4
Conclusion..................................................................................................................................................5
References...................................................................................................................................................6

3
Introduction
Rapid prototyping continues to be a growing as well as evolving field. Rapid prototyping has
been the name provided to the host of the technologies that happen to be used in creating the
physical objects directly from the CAD sources of information. This technology offers enhanced
and opportunities have enhanced in the new markets [1]. The concept has revolved from the
grassroots where small businesses have competed with the larger one in the share market. Frank
billings was another name within this niche market [1]. This individual worked in the Cocable
Organization which designed and manufactured on the specialty cable and its products which are
related to the cables. His main idea was to start a rapid prototyping company [2]. He had to start
somewhere and gain some experience, funding and contact, which was in Cocable Company.
This case study highlights on the things which have occurred in life of Frank billing, how he got
to start his own company and the problems he has encountered in the process particularly in the
project management he was contacted to handle [3]. These issues shows the lack of
communication and the breakdown of the project management process. In this research it will
attempt to highlight on issues such as the lesson learnt in the case, who should take the
responsibility, and what could have been done to make sure the project scope was correct.
Case study assessment:
What lesson can be learnt in this case?
In this case study one of the thing can be learnt is that communication is important.
Communicating with the other team members when working on the project is very important to
its success [2]. A lack of communication could lead to unwanted delays as well as assortment of
other problems. In this case it is clear there was lack of communication particularly there was a
problem with the CAD model which was not compatible with the RP design of Frank. Nobody
between these individuals checked on everything nor communicate how the design should look

4
like [4] On the part of GE Company when the problem of compatibility arose they said they did
not give any maximum length to Cocable Company. In case there was proper communication
channel all the groups involved in the project could have communicated on the progress and no
issues could have arose on the CAD model [2]. There was issue of the blame game. There was
no party which was willing to take the responsibility and take the blame. GE claimed no
maximum length they gave Cocable and the design which they gave them was 62 inches long
and it was weeks ago. On the part of Cocable they did not take responsibility to double check
their RP specs. Organizations needs to shift to the culture of the psychological safety in which
there is rewards of learning from the failure which can be realized fully [5]. Lastly, it is
important to recognize on the weaknesses. one of the most beneficial aspect of having project fail
is the opportunity it allows one to evaluate on any weaknesses and determing on what needs to
be done to strengthen on those areas.
Who do you think should pay for the changes?
I think Cocable should pay for the changes. The reason is that on the part of Cocable they failed
to doable check on their RP specs before they gave Frank the project to work for building the
four RP machines to their specifications [6]. It was their duty to provide the full specs on those
specification to enable Frank to work within the requirements.
Recommendations:
What could have been done to make sure that the project scope was correct?
One way the stakeholders could have done to make sure the scope is correct they would have
communicated well. In all the aspects of management of the scope of any project it lies on the
sturdy foundation of strong and clear communications. These individuals needed to articulate
what they wanted particularly on all the specifications [7]. Cocable organization should have
double checked on their RP specs and gave Frank the details on how the RP machine should

5
have looked like. Moreover, it was the responsibility of GE to also communicate how the design
will look like and the maximum length of the RP they wanted. Additionally, there should have
been clear objectives and requirements [6]. This could have been implemented by having
concrete aims available given that they are going to facilitate the company to virtualize, plan, in
addition to list distinct objectives as well as specifications which would distinct the path for
smart and effective project management.
In this case it would have been important to identify on the limitations. This is an important
aspect since it is very crucial to document what would be done, otherwise individuals could
assume that certain things are to be executed which are not within the budgeted [6]. Frank in his
case assumed on the inches required and decided to put his own measurement, as this was not
clearly defined in the requirements.
Conclusion
In this case it is clear that there is blame game especially when things did not go as planned in
the project scope. In any project it is important to do define the product requirements, the
process, and identification of the limitations and always account for the affected elements. When
these aspects are incorporated in the project, it would become a success. In this case all the
stakeholders involved should have taken the responsibility and became involved in every
milestone achieved in the project.

6
References
[1] Burke, Rory. "Project management: planning and control techniques." New Jersey, USA
2013.
[2] Hajdu, Miklós. Network scheduling techniques for construction project management. Vol.
16. Springer Science & Business Media, 2013.
[3]L. Hossain, "Effect of organisational position and network centrality on project coordination",
International Journal of Project Management, vol. 27, no. 7, pp. 680-689, 2009.
[4]H. Kuklan, E. Erdem, F. Nasri and M. Paknejad, "Project planning and control: an enhanced
PERT network", International Journal of Project Management, vol. 11, no. 2, pp. 87-92, 1993.
[5]Schwalbe, Kathy. Information technology project management. Cengage Learning, 2015.
[6]Turner, Rodney. Gower handbook of project management. Routledge, 2016.
[7]Olson, David. Information systems project management. Business Expert Press, 2014.