Network Project Management: Analyzing Project Failures in MN601 Report

This report analyzes a case study involving a network project management scenario. The project, undertaken by an engineering graduate named Frank Billings, faced significant issues due to poor project management practices. The primary problem was the lack of scope verification, which led to the development of incorrect prototypes. The report identifies several contributing factors, including the absence of standard project management methodologies, failure to conduct stakeholder assessments, and the lack of a change control procedure. Recommendations emphasize the importance of adhering to project management methodologies, particularly the initiation and planning stages, regardless of project size or urgency. The report concludes by assigning responsibility for the project's failures to all parties involved, highlighting the need for clear communication and adherence to project management strategies. References to relevant online resources are also included.

Name of university
MN601 Network Project Management
Rapid Prototyping
Student’s Name
8/26/2017

Network Project Management
Table of Content
Introduction.................................................................................................................................................2
Reason for the causes of Project Management issues................................................................................2
Scope was not verified since the beginning of the project......................................................................2
None of the Project Management Methodologies used.........................................................................2
No Stakeholder Assessment was done....................................................................................................3
Change Control Procedure is missing......................................................................................................3
Recommendations.......................................................................................................................................3
Conclusion...................................................................................................................................................4
References...................................................................................................................................................4
1

Network Project Management
Introduction
Rapid Prototyping (RP) is the modern technology which is capable of developing the exact
replica of in the form of three dimensional models of real equipment or machines 1. These smaller sized
three dimensional prototypes are built to check the efficiency curve or other related parameters.
To brief about the background of the case, an engineering graduate Frank Billings, was very
much enthusiastic to become a leader in the field of RP. After waiting for nearly 3 long years, he got the
first break from Cocable to build four prototypes of the machine as per the given specifications. Once
Frank got the job, he jumped in to for completing the job and handover to client at the earliest.
Reason for the causes of Project Management issues
The main issue being highlighted in the case study is that the scope of work was clear to Frank
and Cocable, but the issue remained is that the scope was wrong. The mercy of the situation is that, this
became highlighted at the end of the project phase when Frank was doing the final testing of the
prototype in presence of Cocable personnel. But the reason why it has happened may be many. Below
are the possible reasons for the issues:
Scope was not verified since the beginning of the project
The issue has happened due to the absence of scope verification step in their project
management practices. After Frank received contract from Cocable, he should have verified the
scope of work according to the practice of project management2. I feel the ‘Kick-Off’ meeting
was also not organized after the handing over of the contract, as in kick-off meeting itself the
scope are made clear by the clients and moreover Frank could have got the opportunity to have
interaction with GE and know their expectations3. The proper procurement procedures as
provided in PMBoK are not followed and it is only because this reason the problem has
occurred. I feel the Cocable, who is the in-between party between Frank and GE has the main
fault of not getting the scope verified by GE and blindly handed the technical documents to
Frank for further development.
None of the Project Management Methodologies used
The project’s main objective was to deliver the four prototypes at the earliest and
Cocable & Frank just did the same, but forgot to follow the standard set of procedures defined
in the project management methodologies4. The procedure tells that the very first stage of the
2

Network Project Management
project management is the development of business case report and the project charter; these
are the document which allows the project to go ahead and selection of project manager who
takes the ownership of the project, which is missing in this case. The documents should have
been developed before start of the job, the scope could have got clarified by GE and this much
of man-hours loss could have been prevented.
No Stakeholder Assessment was done
The very next stage of the above discussed process is the assessment of
stakeholder expectations, in this stage the stakeholders are identified, expectations are
documented, the procedure to meet the expectations are discussed and finalized, the
place of issue resolution is decided beforehand, method of communication is finalized
and the future progress reporting format, time intervals, media of distribution and all
other such issues are discussed and documented properly5. This stage was totally
missing in the case.
Change Control Procedure is missing
There are many project controlling stages which are available in project
management techniques, like the project change control procedure where the
procedures are documented on how to act whenever there is any change of scope of
work or the extra requirement which can impact the triple constraints of the project. If
this document would have been available then, in current situation the methods would
have been clear to all the stakeholders regarding the procedures need to be followed to
resolve the situation.
Recommendations
After thoroughly going through the case study, it can be observed since beginning that the issue
was only related to the scope verification, but then the question also arises that why Frank did not cross
verified it with Cocable before start of the work. But I feel the one simple root cause of the issue is the
‘negligence of project management methodologies’ throughout the project life cycle. None of the stages
as documented in PMBoK is followed and directly the work started without assessing the risks, scope,
quality requirements, finalizing communication matrix and many more.
3

Network Project Management
So the main lessons learnt can be summarized as, for all and any kind of project irrespective of
its size, the delivery time, the urgency, size of scope etc. the project management analysis and
developing of minimum documents are mandatory and the stages of Initiation and Planning stages need
to be performed before jumping to the execution stage, even the monitoring and controlling stages
must also be performed according to the standards and ultimately the close-out by documenting the
lessons learnt of the project.
Conclusion
This is to summarize the whole report, the possible causes of the issues is identified as the non-
availability of clear scope of work till the end of project, none of the project management
methodologies are followed, the initiation stage of the project management technique is totally
neglected and neither the business case study nor the project charter was developed. Even the
stakeholder management procedure was also not developed and the change control system too.
Otherwise the issue which arose at the fag-end of the project could have been identified at mush earlier
stages.
So, now we need to conclude that who need to pay for the changes. At first it looks that Cocable
is the problem party who neither verified scope with GE nor handed the correct specifications to Frank,
but after going through the report, it can be concluded that all the parties are equally responsible for the
issue, as neither of the party insisted for a gathering and finalizing the project management strategies
and it is the only reason of the issue being highlighted so late.
References
x
[1] Udacity. (2017) Building Apps for Web and Mobile. [Online]. https://in.udacity.com/course/rapid-
prototyping--ud723
[2] Andy Jordan. (2012, October) Scope Verification: The Forgotten Process. [Online].
https://www.projectmanagement.com/articles/275424/Scope-Verification--The-Forgotten-Process
[3] Ben Aston. (2016, December) Kickoff meeting: The complete guide to starting projects right.
[Online]. http://www.thedigitalprojectmanager.com/project-kickoff-meeting/
[4] Wrike. (2017) Wrike. [Online].
4

Network Project Management
https://www.wrike.com/download/the_beginners_guide_to_project_management_methodologies.
pdf
[5] OpenCampus. (2017) Manage Stakeholder Engagement. [Online].
https://www.greycampus.com/opencampus/project-management-professional/manage-
stakeholder-engagement
x
5