Top 5 Engineering Project Control Problems to Avoid

Posted by Steven Gentles on Apr 3, 2017 2:12:01 PM

Everyone is familiar with the Apollo 13 mission and how NASA brought astronauts Lovell, Swigert and Haise safely home after an explosion on their CSM. Throughout the ordeal, Mission Control always knew exactly where the Apollo 13 crew were. They also knew where they were supposed to be and what lay ahead and constantly improvised and course corrected to land them safely in the South Pacific.

Engineering project control is no different – control is achieved when you have true project status insight always and you can steer it to a successful conclusion (see my blog How to Improve Engineering Project Control). From my experience, this can be challenging – here’s why.

Apollo13-S70-35013 Mission Control - Project Control at its Best.jpg

Problem #1 – Initial Scope of Work Not Well Defined

Back in the day when I was an aerospace engineering manager, we often struggled to nail down a definitive scope of work for projects big and small. The root causes usually boiled down to one of the following:

  • Design requirements not well defined
  • Initial design approaches and concepts not mature enough
  • Wrong approach to breaking down the scope of work (see Problem #2)

Our main barriers to getting the design requirements right and design concepts solidified out the gate were the usual suspects: time and money. Most projects were late on day one and started life with a long list of ‘known unknowns’ usually attributable to compressed proposal cycles. If designs were an evolution of existing work, and we had sufficient contingency reserve in our plan, everything usually ended up OK. New designs with no contingency reserve? Not so much…

Problem #2 – Creating a WBS with the Wrong Focus

Based on the school of hard knocks, I’ve found that building an activities based WBS is folly. The main problem with an activity based schedule is that it’s pretty much impossible to think of and capture ALL activities. Which means you will not have scoped 100% of the work. Which means your schedule will be crap.

Building a project deliverables focused WBS around the ‘hard’ outcomes of your engineering projects – the tangible things that would be left on the table after the project is completed – is the way to go. This really boils down to a list of project documents like reports, specifications, drawings, models and more. Each are an engineering work package (pretty much exclusively electronic files or document outcomes - see my blog How to Improve Engineering Project Control). Activities like ‘prepare’ and ‘squad check engineering’ should be hung off of each project deliverable and tied off with a milestone planned release date.

Remember: the essence of all engineering projects boils down to the scheduled release of engineering information. A project schedule framed around your project deliverables (engineering work package) is way easier to monitor, track and control than a pile of activities. And you have a much higher probability of capturing 100% of the work that needs to be done.

Problem #3 – Scope Change Mismanagement

Project scope changes are tough to manage if you lack a scope change control system rooted in a robust project change management process. If you don’t have one, by the time your project moves into its final stages, you’ll be left wondering why things are taking so long (and arguing over who should be paying for the cost over runs).

You need to follow these essential change management principles on how to manage scope creep:

  • Only control changes to released documents – this includes contracts, SOWs and schedules as well as engineering information
  • Undertake a change impact analysis to assess the TOTAL costs of a change
  • Articulate the high level benefits of a change
  • The people approving the change (the Change Review Board or Change Control Board) need to base their approval solely on the change benefits and costs (and have the required spending authorizations)

See my blog Document Control Software - What Do You Want to Control Part 3 for more information.

If you need to formalize or evolve your change process, I’d recommend checking out more information available on the Configuration Management Process Improvement Center (CMPIC) or the Institute of Configuration Management. Wikipedia also provides a decent overview of the engineering change management process.

Problem #4 – A Few People Are Devious (But Most Are Just Optimists)

When you ask your project coordinator or document controller to run around so you can get a status update on the project deliverables your engineers are working on, they’ll probably give your PC/DC a glass half full account of where they are at. That’s because most of us are optimists and prefer to deliver good news over bad. It’s also why projects inevitably take longer and cost more than we all thought they would.

See my blog How to Improve Engineering Project Control for how you can fix this.

I have only run into one devious manager during my engineering career. He was the guy who released a drawing package (with all the stamps and signatures) on time and on budget. 25% of the drawings were blank. This went unnoticed by the PM and his boss, but I’m pretty sure it caught up with him eventually (maybe).

Problem #5 – Document Tracking (and Project Tracking) is Hard

If your principal tools are Network Drives, Windows file folders, email and spreadsheets, tracking project deliverables progress requires a lot of running around to get updates from your team of optimists who are authoring documents and files. By the time your project coordinators get everything consolidated into a project tracking spreadsheet report it’s often time to start all over because the information is dated (and probably incorrect to start with).

Network drives, Windows file folders, email and spreadsheets are stone age tools - ee my blog on Why Network Drives Kill Engineering Project Management.

Wrapping Up

Engineering project control is achieved when you have a true status of a project always and you can steer it to a successful conclusion. You will be in control if:

  • You have a tight project scope definition
  • You focus on project deliverables (your engineering document outcomes)
  • You have a mature project change management process
  • You have a team of optimistic realists
  • You are using the right tools to monitor and control project work

(see my blog How to Improve Engineering Project Control)

The first four can be addressed by any qualified, competent and experienced project manager. For more information on the right tools, check out the following video:



Topics: Productivity, Problem Framing, Project Control

Comments Welcome!

Tired of Network Drives, Email and Excel?

Tina5s eliminates the need for network drives and does many of the things that you rely on email and Excel to do when managing and controlling your engineering project information.  

Subscribe to our Youtube channel and see how Tina5s can simplify and transform the way your engineering projects work.

Request a Demo

Follow Tina5s:

Recent Posts