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.2. “Nothing was documented, and we were drifting away from the original project technical specifications”. Briefly discuss the draw backs of adding unapproved changes during project implementation

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.2. “Nothing was documented, and we were drifting away from the original project technical specifications”.

Briefly discuss the draw backs of adding unapproved changes during project implementation