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+1^th 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:

• Project Goal, Scope & Constraints:  what is the project to achieve, and what are specific limitations (see next subsection).
• Project Management Plan describing how the project will be organised and managed.
• Work Break-down:  a break down of all required activities(/components) and the tools/­facilities for that.  A Work Break-down implies that the Basic Design has already been done.  The Work Break-down and the Documentation Plan are good indicators of the effort to be spend.
• Project Plan:  a schedule of all activities, when they start, when they must be ready, and all interdependencies.  For each activity it must be clear which party is responsible (which depends on the specific skills/­capabilities for the specific activity).  Planning multiple activities requiring resources with only limited availability is very complex (and poorly supported in common planning tools).

Goals, Scope & Constraints

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:

• Goal, Scope & Constraints:  what is the project to achieve, and what are specific limitations.
• Organisational Structure:  what groups are involved, and how do they communicate.  Typically there are groups per discipline (area of expertise), but potentially also 'external' parties are involved.  And you probably need to use facilities and services from your own organisation and/or your customer's organisation and/or third parties.
  And consider where everybody can be located.
• Quality:  formal project procedures to assure quality (a chapter in the Project Management Plan, or a separate Quality Management Plan document as described below).
• Documentation:  standards & rules, reviews (a chapter in the Project Management Plan, or a separate Documentation Plan document).
• Monitoring & Reporting:  on milestones, progress, money (material and hours) used against budget.
• Regular Meetings:  attendants, frequency, reporting, follow-up on decisions/­action points.  See Progress Report below for more on that subject.
• Exceptions:  Who is authorised to make exceptions/waivers on the rules/­standards, potentially under what conditions (typical the project manager, but he may have to consult others like a representative of the customer).
  As things never completely go as planned, exceptions to requirements and/or procedures must be possible.  However, it should not be easy to make an exception, and it should never happen unnoticed.  A typical example of an exception is a waiver (e.g. not all components operate satisfactory under the required full temperature range, or a software module does not always produces results within the required response time).  Most waivers are temporary.
• Escalation scheme:  Have an agreed 'escalation scheme' with all major parties involved, describing how to 'escalate' issues in the management hierarchy of each party (and avoid duplication of persons in the hierarchy).

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:

• What quality level is pursued;
• How that quality level is assured during the (development) project (i.e. what QA procedures apply);
• How the operational quality of the product/system will be achieved;
• What documentation rules are applicable (or refer to a separate Documentation Plan document).
• Change management:  how Changes to components and documents are performed (see Change Procedure below).

Considerations

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.

Quality

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

• quality of input material (requirements, components, lower level platform);
• quality of resources (people, tools, facilities);
• quality of the (project) processes; resulting in:
• quality of project's results (intermediate & ultimately the project's product).

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:

• have Document Control and Reviews for all project results (including intermediate results) such as designs, drawings and documents (see Document Reviews);
• have a Change Procedure and a Change Review Board for all project vitals (see Change Procedure below);
• use check lists.
  This may sound trivial, but it is highly effective:  it avoids recurring errors.  Start some check lists and adapt as you learn in practice.

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).

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).

Communication

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:

• When department managers report at a higher level than project managers, you have a departmental organisation:  projects will suffer from departments which have other priorities or feel threatened by the project (department directors which feel their kingdom attacked, rightly or not;  they will publicly support the project, but covertly sabotage it, usually by 'salami tactics').
• When project managers report at a higher level than department managers, you have a true project organisation.  Departments managers will find themselves incapable of providing sufficient people and services (quantitatively and/or qualitatively) on request due to other projects competing for the same resources (and the volitile nature of the requests).  All project managers will always have to compete for priority on resources (and need a way to prioritise between projects).
  Also, project managers tend to ignore potential operational issues;  their priority (and potential bonus) lies with the timely delivery of the project ('after us, the deluge').
• When project managers and department managers report at the same level, you have a matrix organisation:  though priorities are much more balanced than in the pure project organisation, the challenge for project managers will still be to get sufficient priority.

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

Project Introduction

When your project delivers a system in an environment without a previous system, you need to spend a lot of effort in introducing it as the new system completely changes the way personel is used to work.
However, if there is an old system, you have to migrate data from the old system to the new system.  And disruption of the workload is probably not appreciated.
In this case you will have to split the migration in two steps:

1. A trial migration, transferring and converting all old data(bases) to the new system, and test if everything works as it should.  It probably requires several attempts for transfer and conversion before it is satisfactory, and it may take considerable time & effort.
   For the time being, the old system remains active, and the new system is tested in parallel.
2. The real migration:  recent data is transfered, converted, and the new system is now active.  The old system can be kept ready for fall-back for a limited time.

In both cases, Project Introduction is a project in itself.

Planning

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:  Time, Quantity, 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).

'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 out of a magic hat'.  Often the project involves the automation of work processes.  But then you also have: 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:

• Weak project organisation.
  The project team at the customer's side is probably a committee of department heads (i.e. a departmental organisation, not favourable for any project).  Such committees are not known for clearcut decission making and have the tendency to adapt the requirements along the way ('scope creep').
  Of course the supplier should oppose such desires, but it is not easy to keep a strict attitude towards such a customer.
• Power struggles at the customer.
  Department heads in large corporations are often in a struggle for power among each other.  They will use every way to win a fight, including this project as means.  See also Project versus Departemental organisations.
• Obstruction by key personnel.
  Automation probably means less personnel, and the average department head doesn't want a smaller empire.  And if the job of a department is no longer a bottleneck, the department is less important.  Key figures will never openly oppose automation (that would be 'politically incorrect'), but may try to slow down or even sabotage automation (e.g. by 'salami tactics').  For example, if you ask for process descriptions you get half the story.  It is a fight against hidden opponents.
• Over-expectations/over-ambition regarding goals for the product.
  The product is expected to solve all problems in the department, even the rare and irregular cases.
  The client –that is the top management– expects that by automation all of the problems are solved, so that in future everything will be solved by a simple 'push on the button'.  Reality however, is a lot more complicated.  Hardly any job is that simple;  a lot of considerations and choices have to be made at every step.
  Try to automate the bulk of the cases (thereby solving probably over 80% of the workload), and get a good set of rules how to handle the rare cases.
• Over-ambition regarding schedule for project (development and) implementation.
  The customer doesn't seem to understand the effort and time it takes to build/aquire all that is required, and seriously underestimates the time it takes to implement it all in the organisation.
• Intention to use a 'big bang' introduction.
  The customer expects that when the system is ready, it can be introduced overnight.  So the following morning every employee can work on the new system.  Except that the system will still have bugs (initially probably a lot), and the employees are not familiar handling the system.  I.e. a recipe for disaster.

Risks on the Customer

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

• struggle between the customer's departements;
• overambituous goals, the system is to solve everything;
• requirements that seem not to reflect what the customer really needs;
• 'big bang' introduction;
• insolvency of the customer (this is not elaborated any further).

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 to build a case when the 'blaming game' starts.

Risks on Objectives

Actually risks on Goals, Scope & Constraints:

• too many goals (most likely including some conflicting ones);
• overambituous goals (to 'solve all the problems');
• unstable requirements ('scope creep');
• requirements that seem not to reflect what the customer really needs;
• unclear scope;
• vaguely indicated (possibly even unmentioned) restrictions;
• issues with authorities, rules and/or regulations;

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

• Background,
• Objectives,
• Scope,
• Constraints,
• Assumptions,
• Risks, and
• Deliverables.

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:

• Customer:  Do you know this customer or is it a new one (with its own desires, customs/­culture, procedures, rules, documentation requirements, etc.);
• Country:  do you know how to do business there (cultural, legislation & rules, corruption);
• Environment:  (e.g. harsh/arctic/tropical/…);
• Technology:  do you have ample experience with the technology to be used.

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:

• Objectives/Requirements (scope creep or over-ambitious);
• Planning (over-ambitious in time budget);
• Environmental factors as mentioned above, in particular management;
• Staffing problems;
• Availability of facilities and tools;
• Quality.

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:

• time;
• money (budget);
• functionality (or quantity);  and
• quality.

Resources

Risks:

• People:  Many projects exceed the milestones as required quantities of sufficiently qualified people are not timely available (commonly a project ramps up late as people are still on other projects which run late).  Specific skills or training required ?
• Components, material, (prefab) parts:  what about their vendors and the supply chain (quality, reliability, availability) ?
• Money:  is funding reliable, is it unconditional or restricted.  Was the budget (and planning) based on experience (with a nearly identical project), on thorough investigation, or on what was 'politically achievable' (in that case both customer and supplier know it will be going over budget. But you as project manager will get blamed for it).  Are there recurring 'cost cutting' exercises ?
• Time:  This may seem odd, but time is a major factor.  Usually there is a trade-off between time and money (and quality);  adding people may not provide the corresponding improvement in performance (decreasing efficiency of team co-operation / internal communication).
• Facilities and Tools:  can you use facilities and tools when you need them, or is availability severely restricted.
• Suppliers:  If (part of) the project is implemented by a (third party) supplier, be aware that his primary objective is to make money, and making the project a success is second to that at best.  If the project runs late, requires many changes, or doesn't provide all required features, he will like be asked to continue working (and make more money).

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).

Facilities

Risks:

• Infrastructure & services:  offices, office services, utilities, etc.
• Design facilities:  includes modelling, simulation, prototyping.
• Development facilities:  tools, lab, …
• Production facilities:  e.g. scarce (expensive) equipment required for the execution of the project.
• Test facilities: what can they cover, how fast (tools, automation, regression testing);  can they only detect problems or also locate them (i.e. diagnose).
• Rules & Processes:  are there written rules, regulations, process descriptions & work instructions (including reporting, exception handling, management, etc.) how to develop and document the project; are people familiar with them.

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).
Risks:

• Site where the product is going to be developed and/or build.  Are there specific limitations on the site or restrictions on the way the product is to be developed/built;
• Customer/users:  changing desires ('scope creep'), recurring 'cost cutting' (who makes the decisions, i.e. the DMU ?).  Also, the level of expertise of the customer on the subject is relevant;  it may sound contradictory but poor expertise of the customer is a serious risk for the project.
• Lower level platform performance:  is it suitable for the intended purpose (speed & reliability; proven ?).  Are you building on bedrock, sand, or marsh ?
• Co-operating & competing organizations (priority), in particular for resources (staffing, facilities).
  When costs or risks versus gains are with distinct parties in a co-operation, you have diverging objectives for each of these parties – a serious issue for co-operation.
• Community/society:  attitude, are there any 'anti-activists' ?
• Management (project & higher):  experience with (monitoring & controlling) this type of project.
• Key Performance Indicators:  Unbalanced/one-dimensional KPIs may have a profound impact on (operational) quality.

General Tactics

• Investigate the risks/bottlenecks, determine the vital ones and do Risk Management for those.
  When investigating/interviewing persons (e.g. vendors) ask "How many times have you done exactly this before ?  Never / once something similar / many times ?"  Can he make his claims plausible ?
• When there is no experience with some subjects, there is no data to quantify risks.  Try to minimise uncertainty by early prototyping, modelling, trials, etc.
• When dealing with an ambitious goal, in particular on uncharted territory, be aware that automating/­mechanising a system affects/­changes the problem (so the requirements specification does not address the right issues, at least not in the right way).  It is not uncommon to need 3 versions before a satisfactory solution is reached.
  Start small, use a phased approach to learn while profiting from the first achievements.
• Avoid any sudden major steps ('big bangs', 'quantum leaps'):  it looks like major progress can be made in one step but due to fact that so many things change even minor flaws cause so much confusion that progress comes to a grinding halt.
• Make a provisional schedule, and determine the critical path.  Plan idle time ('slack') in the schedule to recover from delays (you may want/need to hide the idle time from customers as there is always pressure to do it in less time, and from engineers to avoid they include it in their development time beforehand).  From that make (the first edition of) the Project Plan.
• Monitor all scarce resources (for the project, e.g. material, equipment, specialists;  for the system, e.g. CPU-time, memory size, disk space), avoid that any margin is silently consumed by developers (scarce resources tend to get more than fully used).
• Be aware of the issue reporting over several hierarchical layers;  every layer summarizes, so 'details' get lost (for reported problems, this is the 'ten little indians' story).  Quantify as much as possible.
• In particular with subcontractors (and subproject leaders, department heads), be prepared for sudden major problems (the proverbial rabbit out of the magic hat).
• Know how the product/result is going to be applied, and look for critical points.  Adapt the Project Plan to ensure success on these critical issues, and do Management of Expectations on vulnerable points in time/­money/­functionality/­quality.
• avoid any 'big bangs' (in integration or introduction/roll-out).
• strictly review all documents produced, and
• regularly assess the state the project is in (i.e. what has actually been achieved versus what was planned, what has changed regarding risks).

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.

«Project» – Progress Report

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:

4. → Yellow flag:  Issues should be clearly visible in black & white documents.
5. ⇒ Red flag:  In particular the important issues.

2  «Area 2»
Etc.

3  Action Points

#	Due	Resp.	Action
«n»	«mm-dd»	«name»	Resolve flag 2
…	…	…	…

• For reference each Action point should have some form of identification.  For example the meeting number/date followed by a sequence number;
• Due date;
• Person responsible for resolving the Action Point;
• Very short description of issue.

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 ?
 

=O=