The management of any project should be planned in two stages. These are:

1. Identify the Work Breakdown Structure – in essence, what are the outputs required from the project.

2. Plan the Project Schedule – how and when the various actions required to create the outputs will be carried out.

The Work Breakdown Structure (WBS)

The first stage in the planning of a project should be the identification of its work breakdown structure (WBS). The Work Breakdown Structure is a tree structure, which shows a subdivision of what needs to be created (or sourced elsewhere) in order to achieve an objective; for example a program, project, or contract. The WBS tells us WHAT elements (outcomes, "deliverables") are necessary to plan, execute, control and close a project, while the (subsequent) project schedule will tell us HOW we plan on creating each of those deliverables and WHEN. In this context, the WBS should always represent exactly 100% of the scope (deliverables) of any project.

It is important to understand that the WBS shows only WHAT the deliverables are. It does not (or should not) show the structure of the deliverables, that is HOW they are individually constructed. (It makes perfect sense to do that too using IQ, but the initial WBS should not be confused with that product structure; in fact my practice is to make that subsequent structuring or design process a part of the product structure - I use outlining in PowerPoint and Word, for example, when a project deliverable is a document or a presentation.)

Nor should the initial creation of the WBS be confused with the subsequent stage of project scheduling, which identifies the schedule of tasks and their interdependencies – the HOW and the WHEN. It is considered poor practice to construct a project schedule before designing a proper WBS.

So the WBS is neither a complete project plan, nor a schedule, nor a chronological listing.

In a project or contract, the WBS is developed by starting with the end objective and successively subdividing it into manageable components in terms of size, duration, and responsibility (e.g., systems, subsystems, components, tasks, subtasks, and work packages). Thus it includes all deliverables necessary to achieve the objective. This should normally take the form of a tree structure.

The most obvious way in which to model a tree structure in InfoQube is of course as a hierarchical outline. However, this is not actually necessary in order to plan a project nor – subsequently - to represent it as a Gantt chart.

The Work Breakdown Structure provides a common framework for the natural development of the overall planning and control of a project or contract and is the basis for dividing work into definable increments from which the statement of work can be developed and technical, schedule, cost, and labour hour reporting can be established.

A work breakdown structure permits summing of subordinate costs for tasks, materials, etc., into their successively higher level “parent” tasks, materials, etc. See www.sqlnotes.net/drupal5/index.php for how to create such hierarchy or column equations.

For each element of the work breakdown structure, a description of the task to be performed is generated. This technique is used to define and organize the total scope of a project.

The WBS should initially be organised around the primary products of the project (or planned outcomes) instead of the work needed to produce the products (planned actions). Since the planned outcomes are the desired ends of the project, they form a relatively stable set of categories in which the costs of the planned actions needed to achieve them can be collected.

An outcome determines a so-called terminal element of the project, that is, an activity which delivers that outcome. A well-designed WBS makes it easier to assign each project activity to one and only one terminal element of the WBS, which is desirable in phased projects which deliver multiple outcomes and for which – for example – separate costings / billing items are required or desirable as part of the process of accounting for project costs.

A Gantt chart is a type of bar chart that illustrates a project schedule. InfoQube has a Gantt view, which includes a Gantt chart.

Gantt charts illustrate the start and finish dates of the terminal elements and summary elements (intermediate elements) of a project. Terminal elements and summary elements derive from the work breakdown structure of the project. Gantt charts can also show the dependency (i.e. precedence network) relationships between activities. Gantt charts can be used to show current schedule status using percent-complete shadings. Gantt charts have become a common technique for representing the phases and activities of a project which carries out a work breakdown structure (WBS), so they can be understood by an audience which is wider than the person who is planning the work.

InfoQube cannot pretend to the advanced project management capabilities present in dedicated project management software such as Microsoft Project. However, IQ does include powerful work management capabilities which, crucially, can easily be integrated with the other information management needs of individuals. This documentation assumes that InfoQube is being used to manage the activities associated with one person carrying out a complete project. The size of an action is measured in person-days of effort. Normally, its duration is determined by its start date and its end date; however, it is no longer required to set the Gantt chart End Date and Duration field. When only the Start Date field is set, this can be used to get a timeline-type view. An action which takes zero time is called in IQ a milestone; it is represented not as a line in Gantt view, but as a lozenge.

In a project schedule, dependencies between actions are identified. Where one action cannot start until one or other earlier actions have been completed, the action has a dependency upon those actions.
 

The implementation of projects in IQ usually involves a combination of specific IQ features. These are:

1. Gantt View. This can be enabled for any grid, although typically it is used with a Projects grid. To toggle Gantt view on or off for a given grid, use Grid / View Gantt. To set the Gantt-related properties for a grid, use Grid / Properties and open the Gantt Chart properties for that grid.
2. A set of system fields. These are together used intended to represent Projects.
   

The system fields include:

Part of the flexibility of IQ is that it is not necessary to stick to a strictly hierarchical breakdown of work. Thus an element of one project may equally be used as an element of a second project.

Thus one thing which is essential to effective project planning in IQ is grouping together tasks which together constitute a project. It might therefore be sensible to represent the project as a tree structure of hierarchically-linked tasks and their sub- and sub-sub- tasks. However, this is not in fact the way in which IQ shows how tasks are related. Instead, IQ permits task dependencies to be represented and stored explicitly. One task can depend on more than one other task, and one task can precede more than one subsequent, dependent, tasks. Thus, it is only by convention that tasks and sub-tasks are represented as a hierarchy, and IQ ignores the tree structure when considering dependencies. Instead, it relies upon the use of the two system fields TaskID and NextTaskID to show how each task relates to others.

Traditionally in project management, project tasks are labelled using letters. However, IQ uses the numerical system field TaskID to identify individual tasks which participate in dependencies and the system field NextTaskID to store dependencies. In fact, the NextTaskID field can be used to identify several “next” (dependent) tasks since it takes the form of a comma separated list. It should be noted that when a dependency is established, completely new values are created for TaskID and NextTaskID - they have nothing to do with the IDItem field associated with all IQ information items.

The standard sample database contains a project called Somiro. The screenshot which follows is taken from such a sample database.

 

In the screenshot we can see the following elements:

1.      A TLI (top level item) ‘Project Samiro’ and its constituent tasks, here labelled 1.1 to 1.11; this grid shows the principal fields needed to implement a Gantt chart in IQ; these fields are discussed below.

2.      Above the grid is shown the project overview – this extends over the whole length of the project, which is here all of May and most of June 2008; it is shown if the Gantt Chart property Show Overview is set; the scale of the display can be set to one of Min, Hr, Day, Wk, Mo (minutes, hours, days, weeks, months).

3.      To the right of the main grid is shown the magnified detail Gantt view of the tasks which are active in a particular seventeen day period; the part of the project which is currently displayed is indicated by orange shading in the project overview described in the previous element.

4.      Below the detail Gantt view is the resource utilisation histogram; it is shown if the Gantt Chart property Show Histogram is set.

Right-clicking the date line at the top of the Gantt view displays a menu which permits the Show Overview, Show Histogram and Zoom parameters to be changed; Gantt properties are also accessible from this menu. In general, IQ synchronises what is shown visually in the Gantt View and the corresponding fields in the grid; it is therefore a matter of user choice whether to change grid values using primarily the keyboard, or Gantt view values using the mouse.

Gantt charts are good for project management, but they can also be used for other things, since:

1. The amount of scaling is under user control.
2. The current time is shown as a green vertical bar in the minute, hour and day scales.
3. If you double-click on the header, that is, the dates bar, the chart is centred to the current date/time.
4. If you double-click on the chart on an item line, the chart is centred on that item bar.

5.      Using the mouse-wheel when over the Gantt scrolls the chart:

1. No modifier: Up/Down
   
2. Shift: Zoom In/Out
   
3. Ctrl: Left-Right
   

6.      As the user moves the mouse, a Date Ticker (a grey open bar) is shown just below the date headers.

1. Mouseover - positioning or hovering the mouse above an item in the Gantt view; note that the mouse cursor may change shape, for example to a pair of vertical bars, or to a percentage sign, depending on where the mouse is positioned over an item and what the existing grid values are for the item;
2. Select - when the user clicks on the left mouse button; the exact behaviour depends on what the cursor is showing when the item is selected;
3. Drag - when the user, having selected an item and keeping the mouse button down, moves the mouse, an item may be extended in length, or another property may change; again, the exact behaviour depends on what the cursor was showing when the item was selected.

Grid: Item colour: an option has been added to select which columns are shown in that colour.

Currently, the item back colour is set to all columns. This is sometimes not desired (in particular with the new Gantt chart bar colour). The new option permits setting the list of fields which show the color; it should be left blank to color the whole item:

Additionally, in a Gantt chart:  an option has been added to set Gantt item bar colours. The steps necessary are these:

1.      Grid>>Properties>>Gantt Chart>>Bar color field : set it to field containing the color (by default, the ItemColor field is used)

2.      Set the values for the bar colours (using ItemColor field is easy because IQ has context menus to set this field)