Last update   PvD

Project Management

The term project is typically used for a one-time undertaking i.e. to develop or construct a unique product, and not for just creating the N+1th item like in series manufacturing.  Admittedly, the distinction is not always very clear, e.g. is developing 'something similar as before' a development project ?  Building a similar object –or even the same object– under quite different conditions could be a unique project.  And assembling a customised system (e.g. customer or site dependent) using standard components could be a project.
A project invariably encompasses engineering to some extend.

Project Management is to see that a determined goal is achieved within a determined time and within a determined budget:  create the conditions for the project to make it a success.  Good project management must also take some bad luck, mishaps, minor failures, delays, etc. into account as those are likely to occur to a more or lesser extend.  Those are considered risks to the success of the project (even if it only delays the delivery).

This page is not about yet another Project Management Method, but discusses risks for projects where the customer is a large organisation.  One part of Project Management is about creating (organisational) structures and rules to produce the desired results and the supervision to assure compliance, and the other part is about handling the risks.  We will first discuss Project Structure & Rules and some considerations before going into specific risks and counter tactics.
See also Projects & Contracts about different types of projects and contracts with their specific (risk) aspects.

Project Structure & Rules

For a succesful project you need:

Goals, Scope & Constraints

Before starting anything for a project, you need to know what the Goals, Scope & Constraints of the project are (this will become a section in the Project Management Plan discussed below).
For all Deliverables you must have Requirements or at least Acceptance Criteria.

In particular for 'lump sum' projects, state that above documentation is leading and has priority over the 'general terms and conditions' for delivery/services from the customer.

Project Management Plan

A Project Management Plan describes how the project will be organised and managed, with specific sections (or reference to separate corresponding documents) regarding:

Quality Management Plan

A Quality Management Plan is the Quality Assurance document for the project to produce good results.  It is strategic document like a Risk Management Plan.  Whereas a Test Plan reflects the product under development, this Quality Management Plan reflects all effort (i.e. including development procedures), and delivery & operational test.  It describes:


Budget:  Time & Money

In most projects, time is more or less equivalent to money:  if a project exceeds its time budget by a factor two, be sure that its costs (manpower) are also twice as much.  There are only two exceptions:

  1. When extra money is used to pay for overtime and/or extra manpower (i.e. trade-off money for time:  more money but still within time limit).
    This is only a limited solution, as overtime or extra manpower is only activated when schedule overrun is imminent:  too late to make a big improvement.  Long periods of overtime causes fatigued and less effective personnel.  And more people require more inter-communication and often a learning period, hence a loss of efficiency.
  2. Some jobs need time, or a single resource.  For example, concrete needs time to cure so you can't improve the speed by working day and night.  You can't work with a lot of people in a small space ("you can't paint a toilet using 10 decorators").  And you can't have a baby in 3 months by using 3 women.

Note that money impacts all resources:  people, tools, facilities, etc.


There are various aspects of quality involved (which form a risk for the project), most importantly

On the first two points, a project manager has marginal influence (for the greater part by having quality checks at entry, but any rejection will probably cause delays).  But the last points are the full responsibility of a project manager.
He can introduce serious quality control procedures, but that will consume a lot of time and slow down progress.  He should set a minimum of standards allowing him to control quality (i.e. relax or strengthen rules as practice learns).  The main points are:

Trade-off:  Quality, Functionality, Time & Money

Here functionality (capabilities, as in software) is equivalent to quantity for some other areas. 
More quality and/or more functionality requires more time, and therefore more budget (time=money).  Key to remain within budget is to limit both quality and functionality;  however there is a minimum quality and functionality required to achieve the project goal !  Here is a major strategic choice (dilemma) for the project manager.

Limit your initial project to a modest goal:  strip all 'nice to haves' from the first release.  Management of Expectations may help to make humble ambitions in this regard acceptable for your customer.  Prioritize features according to:

  1. Must have this (essential, won't work without it);
  2. Should have this, if at all possible (major feature but it works without it);
  3. Could have this if doesn't affect anything else (very desirable to have); and
  4. Won't have this now, but would like it in the future (i.e. for the next release).
{The above list is also known as MoSCoW.}

Determining the minimum required qualify is extemely difficult (better be on the safe side).  "The bitterness of poor quality remains long after the sweetness of low price is forgotten" (Benjamin Franklin).

Team Size

The size of a group is important for its management;  up to about 6 people you can have a team leader (who is also doing work himself);  above that you need a supervisor (up to 18 ?) or a manager (adding a hierarchical layer, but who can manage up to 20‑50 people depending on the variety of their work).
Preferably, the managers/­representatives of the various teams/­parties have about the same importance (i.e. report to equivalent levels in the hierarchy).


As a project comprises the co-operation of many people, communication –i.e. the interchange of information– is vital.  But communication is also overhead (when you are talking you are not productive).  So make it as effective as possible.

Analyse where and what communication is required at what (potentially changing) intervals, how (what form: speeches, meetings, reports, documents, news letters, etc.) and organise it.  This can be formalised in the Project Management Plan (e.g. meeting schedule) and the Documentation Plan.  But also promote some informal encounters (e.g. 'coffee corner' and 'friday afternoon drink'-like).

The Purpose of Project Management

It is important to realise that Project Management is not just to assign jobs/­problems to the appropriate discipline:  it is to resolve all relevant problems in the project.  Of course Project Management is to support inter­disciplinary problem resolution.  But even if a problem is basically restricted to a single discipline, assistance from other disciplines under control of Project Management may help to solve that problem quicker – important when that problem may endanger the schedule.  That is the added value of good project management.

Project versus Departemental organisations

In most organisations you have departements (commonly for a specific area or discipline), and projects which involve multiple departments.  The levels at which department managers and project managers report in the organisation hierarchy is relevant:

Above is true for your own organisation, but also for your client's (and involved third parties).

'Political' customers

Some charateristics (risks) are typical in projects for large corporations and/or governement organisations, where (departemental) politics play an important role in the background.  Objectives/­constraints/­requirements may shift over time, and previously unmentioned issues may appear like 'rabbits from a magic hat'.  Such projects are a risk in itself;  they do require special handling, but even then the project might fail:  they represent a 'lose-lose' case as the objectives aren't met even though the project implementor is exceding its budget (lump sum ?).

Other characteristics common for such an organisation:

Process Automation

Often the automation of work processes fail.  Such work occurs in large and/or governmental organisations, so all the characteristics of a 'political' customer apply.  But then you also have:


A good planning should take a 'reasonable' amount of bad luck, mishaps, minor failures, etc. into account as these are part of everyday life (major mishaps are supposed to be so rare that they are usually not taken into account — the required measures would probably also take extraordinary costs).  The simple way to solve that is to incorporate some slack in the planning.  That however proves to be rather cumbersome.

When you plan spare time in the schedule, your customer may insist on squeezing the schedule.  And when you extend the alloted time on planning items, the engineers/­subcontractors will use that.  So you must find a way to add time while avoiding the above mentioned problems.
A workable solution is to plan a test or audit at the finish of each component (in particular on components on the critical path);  the use of tests/­audits is reasonable and will find little opposition.  Initially you will probably even exceed the test/­audit time, but later on it it should take neglible effort and time.  And it improves the overall quality, and prepares for the final system tests.

Risks & Tactics

The risks for a project can only be analysed in general;  we do that according to the Objectives, Resources (& Facilities), Environmental Factors, and Management.  The usual issues are timeQuantity, Quality and Availability of material, resources (people) and facilities.
Here the risks will be listed with potential tactics to mitigate them.  In general, make sure that a risk is not applicable for your project before ignoring it !

Invested resources represent costs and risks (potential costs).  Delays mean that people are working longer (extra costs), and that the product will provide the promised gains later.  The risks in a project will be more clear –and possibly less– when there is already experience with similar projects.  Investigate what went well and what what wrong in those projects, and learn from that.

The most costly component is commonly either the human effort or the raw material (typical exception is when temporary/­introductory measures have huge consequences for existing services).  The (minimum) costs in a project should be quite clear; they are the invested (development) resources.  Note that additional investments may be require before the project results –the product– turns into a success (e.g. marketing campaigns).

Risks on the Customer

Risks:  (typical for 'political clients' and process automation)

Tactics:  Start modestly, use a phased approach or an 'ink stain' approach, create a 'pilot project'.  It demonstrates the benefits and issues for the project, and creates mutual trust and forms a stable starting point.  Then you can decide what the best way is to continue and expand on that.

Analyse the working processes, and find the most labour-intensive ones.  Commonly 20% of the processes require 80% of the effort:  those are the processes which should be tackled first, if necessary by 'island automation'.  Automation of these processes provide credit for the automation supplier, and releases the pressure on work for the customer.
After that, expand the 'islands' and start connecting them.  And test thoroughly.  And don't be surprised if the requirements will have to be adapted.

Take into account that reality is much more complex than is apparent from the job descriptions and/or requirement specifications.  Start formalising the work processes without actually introducing IT, for example by describing actions ('work instructions') and introducing forms for data & results at interfaces between processes (i.e. the first steps for work process re-engineering).  This creates a kind of detailed specification.  Then start introducing IT.  Be aware that automation often moves a bottelneck (i.e. automation changes the problem).
Work in modest steps.  Validate each step, and check whether it completely solves the corresponding task or that a further version is required.  And make sure that project management is actually leading.

Be very careful at unifying data over several departments (sub-processes):  apples and pears may be just fruit for most of the organisation, for some departments the distinction can be crucial.  Such issues can often be solved in the (tele-)communication interfaces.

Avoid all politics as you won't win from your customer's managers (though it may not lead to a succesfull project);  remain polite and report manipulation attempts along the escalation line.  When such reports are in writing, it may help build a case when the 'blaming game' starts.

Risks on Objectives

Actually risks on Goals, Scope & Constraints:

Tactics for Goals, Scope & Constraints:  Make sure you have a documented agreement on: (BOSCARD)

The BOSCARD-list does not cover all of the above mentioned risks.

Another approach for risks is considering the experience and lack of experience in the aspect areas:

If only a single aspect is negative, you run considerable risks (i.e. don't expect to make a profit on that project);  if two or more aspects are negative you will fail.

Major Risks

The major risks for a project are:

An over-ambitious project schedule is a serious risk for your end-milestone (your bonus ?), but not necessarily for the project as such (even while late it can still be successful).

Many risks can not be controlled by a project manager, but he must certainly try to mitigate them.  The main area where a project manager is directly responsible for, is to find the balance between:



Tactics:  Most of these risks are outside the handling scope of a project manager;  what he can and must do is monitor these closely, and report any transgression as red flags and involve higher management to resolve these issues (i.e. escalate the issues).



Environmental factors

Factors which can hardly be influenced by project management, but may have a considerable impact on the project (and therefore present a risk).

General Tactics

See Project Aspects for a list of aspects of a project to develop and deliver a system to a customer.
See also considerations on Software Reuse.

Documents & Procedures

Note that the documents mentioned in this webpage are of general nature, but potentially specific for a project.  So it is possible to refer to some general standards, rules and/or procedures, or copy the corresponding document of an existing project and adapt that for this project's specifics.
A project can be considerably aided by including a documentation specialist as support;  he will ease the work of all developpers and see to it that the documents conform to the rules.  See also the documents Project Management Plan and Quality Management Plan discussed above.

Change Procedure

Once a project is underway, any change on the requirements, conditions or methods may have a serious –unplanned– impact.  Therefore such a change should not be allowed without serious deliberations.  The route to follow is called the Change Procedure and involves the following:

Change Request
The request for a change should be clear:  what behaviour­specification should be changed, and why.  Requested by the customer, or internally as there seems to be a problem or a potential improvement.  The Change Request is handed to somebody responsible for making the Change Proposal.
Change Proposal
Also called Engineering Change Proposal: ECP.  After investigating the Change Request, the proposal may show multiple solutions, each with the impact quantified.  The impact is typically on other components & documents to be modified, and is quantified at least in terms of schedule and effort/budget.
Change Review Board
A committee with knowledgeable people from all departments involved in this project/­system will evaluate and review the Change Proposal and decide either to reject or approve it (preferably with arguments for either decision), or send it back for additional investigation/­elaboration.  It may also decide to postpone the change to a new release (i.e. add it to the Requirements for the next release).
Change Order
The approved Change Proposal should have a list of items (requirements, components, documents, work methods, etc.) which should be adapted in a described way.  This has to be executed.

Clearly, the Change Procedure is a lot of work, but it makes the project much more stable and controlled.  And many changes will be trivial and can be processed without much effort.

Note that the cost of a change increases about ten-fold (!) when the development progresses to the next level (top-level design, detailed design, coding, testing, production & roll-out).

Progress Report

To manage (the progress of) the project, there will be regular meetings to discuss progress and issues.  The frequency of such meetings depends on the rate of change in the project;  at least once a month up to once a week is common, but when there are pressing issues extra meetings will be held.  Of all meetings, a report should be made.  But a Progress Report is a special case of the common Minutes of Meeting (MoM) report.

Application Note
Replace all text between «angel brackets», adapt and complete text.
Delete this Application Note.
  • This document is either a 'Progress Report' or a 'Status Report'.
    Usually a 'Status Report' is made incidentally, and the 'Progress Report' at regular intervals (week/month).  The terms are considered almost equivalent.

«Project» – Progress Report

Distribution listPresent
«name1»     «email address1»     y/n
«name2»«email address2»y/n
  …  …

1  «Area 1»
If you have to cover multiple areas/­subprojects, use separate sections for each area.  You may use a short introduction to each area.

For each area, discuss the issues and flag them:

  1. Green flags:  Milestones passed successfully, issues resolved, risks averted.
  2. Yellow (or Orange) flags:  Potential issues, what the potential consequences are, and a reference to the Action Points list (measures to solve the issues).
  3. Red flags:  same as Yellow flags, but for actual issues or issues with potential disastrous consequences, and/or where counter­measures are probably insufficient.
    Red flags should trigger (higher) management for support (resources, priority, etc.).

You can use colours for the flags to attract more attention, but keep in mind that photo­copying and/or black & white printing will not display these colours.
A special bullet can also do the trick, but then you can not use numbered lists.  A combination may do the trick. Example:

  1.  Yellow flag:  Issues should be clearly visible in black & white documents.
  2.  Red flag:  In particular the important issues.

2  «Area 2»

3  Action Points
«n»«mm-dd»«name»Resolve flag 2
  …   …  …

When an action point has been completed, it can be removed from the list.  However, it is a good idea to keep them in some background list ('solved issues') for later reference.

A project is only successful when it leads to a new project.

If you are in a hurry, sit down first and think.
Don't start working without a good plan — you will regret it.

Phases in a (develoment) project:

  1. Wild Enthusiasm
  2. Disenchantment
  3. Total Confusion
  4. Search for the Guilty
  5. Punishment of the Innocents
  6. Promotion of the Non-participants

What phase is your project in ?