I was brought in as the project manager of an advanced vehicle development project during the detailed design phase. The previous project manager had to resign from our company due to health reasons. My customer was the U.S. Department of Transportation. I had a team of six automotive design engineers working on my team. When I came into the project, the first thing I did was to learn the advanced vehicle specifications and the deliverables’ timeline. Then I learned the responsibilities and capabilities of every team member. I went to Washington, DC from California to meet with my customer’s project manager and to generate a close rapport with him. According to the original schedule, we were about two weeks late and the project was running over budget by 6% when I took over. One thing that bothered me was that my customer’s project manager was accustomed to phoning my team’s design engineers and ordering minor variations to the specifications without my knowledge. Nothing was documented and we were drifting away from the original project technical specifications. Apparently, the previous project manager closed his eyes to these minor specification variations and my customer’s project manager got used to forcing these minor specification changes on my design engineers. The first thing I did was to have an emergency team meeting. I went over all pending redlines that were not released through document control. The original specifications were still at revision A. I asked my team members not to accept any changes to the specifications without my knowledge. If a specification change was requested by the customer over the telephone, it did not matter how minor the change request was, it had to go through me. We all agreed to the new strict specification change rules. I revised the specifications to revision B and sent it to my customer’s project manager for his approval. Then I asked my customer’s project manager to travel to our plant so that we could finalize the revised technical specifications. I sat with him for three days face-to-face to go over each redline and got his final approval for revision B to the contract’s technical specifications. I told him that we were falling behind in the project due to the minor changes that were piling up. I asked him politely to go through all the changes with me whether they were minor or not. I told him he could talk to the individual design engineers as many times as he wished, but if there was a change looming on the horizon, he had to go through me. I emphasized that if the change was urgent, I could redline the technical specifications, sign it, and release it to the responsible design engineer that same day. Then I could have the technical specifications go through an official revision after piling up a couple of minor changes. If a change were going to affect the project schedule and cost, then I would provide him with my new schedule and cost estimates. I then could get the change approved and implemented only after his written concurrence with me regarding the new project schedule and project cost. He agreed with me on all my scope change procedures. I kept the project technical specifications current. I made sure that changes went through our document control with top priority. I always kept my design engineers on top of the technical specifications. I reviewed all the changes during our weekly team meetings. When the project design phase was completed after nine months, the technical specifications were at revision K. Similar technical specification control rules apply between your subcontractors and your company. Your customer should not be able to go to your subcontractor directly and ask for a scope change. Technical specifications make up one of the critical legs of a project structure. The other three critical legs of the project structure are the schedule, the cost, and the team. If one of those legs is out of sync, the project will start to wobble, lose control, and sink. As project managers, we will definitely fail. Keeping the scope changes of a project under tight control without causing your customer to become frustrated and angry is a must. LESSONS LEARNED FROM THIS PROJECT EVENT • Taking on a project in the middle of execution is very courageous and risky. • You must absorb and evaluate all aspects of your new project very fast. • You must initiate changes to project activities that you see as inappropriate. • It is always quite challenging to be able to change old established habits in a project environment. Source: Atesmen, K. (2015). Project Management Case Studies and Lessons Learnt. Boca Raton: Taylor & Francis Group 1.1. “One thing that bothered me was that my customer’s project manager was accustomed to phoning my team’s design engineers and ordering minor variations to the specifications without my knowledge. With reference to the case study, briefly explain the phenomenon which the project was experiencing.
Critical Path Method
The critical path is the longest succession of tasks that has to be successfully completed to conclude a project entirely. The tasks involved in the sequence are called critical activities, as any task getting delayed will result in the whole project getting delayed. To determine the time duration of a project, the critical path has to be identified. The critical path method or CPM is used by project managers to evaluate the least amount of time required to finish each task with the least amount of delay.
Cost Analysis
The entire idea of cost of production or definition of production cost is applied corresponding or we can say that it is related to investment or money cost. Money cost or investment refers to any money expenditure which the firm or supplier or producer undertakes in purchasing or hiring factor of production or factor services.
Inventory Management
Inventory management is the process or system of handling all the goods that an organization owns. In simpler terms, inventory management deals with how a company orders, stores, and uses its goods.
Project Management
Project Management is all about management and optimum utilization of the resources in the best possible manner to develop the software as per the requirement of the client. Here the Project refers to the development of software to meet the end objective of the client by providing the required product or service within a specified Period of time and ensuring high quality. This can be done by managing all the available resources. In short, it can be defined as an application of knowledge, skills, tools, and techniques to meet the objective of the Project. It is the duty of a Project Manager to achieve the objective of the Project as per the specifications given by the client.
I was brought in as the project manager of an advanced vehicle development project during the detailed design phase. The previous project manager had to resign from our company due to health reasons. My customer was the U.S. Department of Transportation. I had a team of six automotive design engineers working on my team. When I came into the project, the first thing I did was to learn the advanced vehicle specifications and the deliverables’ timeline. Then I learned the responsibilities and capabilities of every team member. I went to Washington, DC from California to meet with my customer’s project manager and to generate a close rapport with him.
According to the original schedule, we were about two weeks late and the project was running over budget by 6% when I took over. One thing that bothered me was that my customer’s project manager was accustomed to phoning my team’s design engineers and ordering minor variations to the specifications without my knowledge. Nothing was documented and we were drifting away from the original project technical specifications. Apparently, the previous project manager closed his eyes to these minor specification variations and my customer’s project manager got used to forcing these minor specification changes on my design engineers.
The first thing I did was to have an emergency team meeting. I went over all pending redlines that were not released through document control. The original specifications were still at revision A. I asked my team members not to accept any changes to the specifications without my knowledge. If a specification change was requested by the customer over the telephone, it did not matter how minor the change request was, it had to go through me. We all agreed to the new strict specification change rules. I revised the specifications to revision B and sent it to my customer’s project manager for his approval.
Then I asked my customer’s project manager to travel to our plant so that we could finalize the revised technical specifications. I sat with him for three days face-to-face to go over each redline and got his final approval for revision B to the contract’s technical specifications. I told him that we were falling behind in the project due to the minor changes that were piling up. I asked him politely to go through all the changes with me whether they were minor or not. I told him he could talk to the individual design engineers as many times as he wished, but if there was a change looming on the horizon, he had to go through me. I emphasized that if the change was urgent, I could redline the technical specifications, sign it, and release it to the responsible design engineer that same day. Then I could have the technical specifications go through an official revision after piling up a couple of minor changes. If a change were going to affect the project schedule and cost, then I would provide him with my new schedule and cost estimates. I then could get the change approved and implemented only after his written concurrence with me regarding the new project schedule and project cost. He agreed with me on all my scope change procedures.
I kept the project technical specifications current. I made sure that changes went through our document control with top priority. I always kept my design engineers on top of the technical specifications. I reviewed all the changes during our weekly team meetings. When the project design phase was completed after nine months, the technical specifications were at revision K.
Similar technical specification control rules apply between your subcontractors and your company. Your customer should not be able to go to your subcontractor directly and ask for a scope change.
Technical specifications make up one of the critical legs of a project structure. The other three critical legs of the project structure are the schedule, the cost, and the team. If one of those legs is out of sync, the project will start to wobble, lose control, and sink. As project managers, we will definitely fail. Keeping the scope changes of a project under tight control without causing your customer to become frustrated and angry is a must.
LESSONS LEARNED FROM THIS PROJECT EVENT
• Taking on a project in the middle of execution is very courageous and risky.
• You must absorb and evaluate all aspects of your new project very fast.
• You must initiate changes to project activities that you see as inappropriate.
• It is always quite challenging to be able to change old established habits in a project environment.
Source: Atesmen, K. (2015). Project Management Case Studies and Lessons Learnt. Boca Raton:
Taylor & Francis Group
1.1. “One thing that bothered me was that my customer’s project manager was accustomed to phoning my team’s design engineers and ordering minor variations to the specifications without my knowledge. With reference to the case study, briefly explain the phenomenon which the project was experiencing.
Step by step
Solved in 2 steps
