An “Engineering Guide” to agile project management

Project management has become, in many cases, a self-justifying and overly time consuming occupation, acting as overhead to projects and retarding potential progress. This guide aims to show how this effect can be minimised with additional guidelines or rules that will benefit the project, especially in the early stages between project start before the production phase begins. An over-reliance on processes early on when the project is in an increased state of flux also retards potential progress.

No engineering guide would be complete without a reference to Kelly Johnson’s ’14 Rules of Management’ which were formulated and successfully carried out during his time at Lockheed Martin Skunk Works.

But there should be no hard-and-fast rules. Each project is different, run in a different environment with a different group of people and there are no catch-all solutions that will always give an optimum solution.

The key parameters to keep in mind throughout are:

The project flow is shown as an iterative process, starting with an initial set of specifications (generated from customer requirements) which are updated as the design develops. Here the feared ‘scope creep’ can be harnessed as a powerful positive effect as it is primarily restricted to the early modelling and prototype stages which are rapid. It is expected at this stage that a range of suggestions (resulting from modelling and prototyping) are submitted to the customer in order that the base requirements could be modified (note this is a major deficiency in the present systems engineering philosophy).Her

The usual project flow has been modified to highlight early stages including modelling and prototyping. These are regularly missed in contemporary project phases where the focus is on production. Modelling in this case refers to business models (financial and budgetary), operational models (use cases, functionality) and system models (component, subsystem, algorithms), as well as specialist modelling where appropriate (such as FEA or thermal analysis). This is an incredibly important step as it gives confidence that the product is technically and commercially feasible before any ‘metal is cut’. The models are intended to be kept up to date throughout the project from their creation onwards and validated against prototypes and production output when possible.

Project rules:

Personnel:

• No more than 10-20% of the engineering team should be ‘managers’
• Staff numbers to be kept to a bare minimum
• A multi-disciplinary engineer (or systems engineering team for excessively large or complex projects) should lead project decisions
• Using multi-disciplinary engineers eases resourcing issues and will optimise workloads

Planning:

• Mid and Long Term planning to be minimised except for key dates/deliverables and framework
• Budgetary considerations are to be kept updated weekly – project spend and forecast
• Non-essential documentation to be minimised. Essential documentation to be done to high standard.

Engineering team:

• Teams to be co-located for ease of communication
• Teams will be responsible for allocated tasks
• Designing engineers will be responsible for testing
• ‘Beating deadlines’ will be rewarded

Meetings:

• Restrict attendance to required personnel only but publish minutes
• Meetings shall always have actions
• Meetings should occupy no more than 1 hour per day for engineering personnel

Other:

• The customer shall have open access at all stages of the project
• Decisions will be timely
• The rules are flexible, at the discretion of the lead engineer
• Common sense can replace 90% of processes, especially at the start of the project